1. I don't think it needs to implement Action, I think it is Describable that makes it show up in the breadcrumb, but I'm not sure (I've forgotten half of the thinks I learned before my vacation).
getDynamic is also just a special method that stapler can use, you could also just have a method called for example getServer. The difference would be in the url
  _"jenkins/gerrit-trigger/serverIdOrName"_ in the getDynamic case and 
  _"jenkins/gerrit-trigger/server/serverNameOrId"_ in the getServer case
I don't have any special preferences in either case. The url using getDynamic "looks better" on the outside, but one thing that is working against it is thet getDynamic is evaluated last, so if the GerritManagement class has any doX or getY methods you won't be able to have any server keys/names of X and Y which could be a bit confusing maybe. But that is mostly corner cases.
2. I wrote nameOdId and name/id above because this is also a bit of a trade off decision. Using an id will make most things easier with renaming as you don't have to go through all projects, rename the value where needed and save it do disk (on our system we have 10k projects to loop through), the name is just another attribute of the server.
But an Id would make the to the config page a bit "not Jenkins" as other things like slaves and jobs use the name to navigate to. In the Build Failure analyzer we used an id because it can have a database as back end storage, so the choice there was easy, and in the Team Views plugin we used the team name as the key because we wanted it as similar to the User views as possible.

So I guess that an id/key approach would be better, but if you have stronger feelings for using the name and handling renames then go for that. If you go for a generated key approach then the drawbacks of using getDynamic disappears as well :)