Weighing in on a 2 day dead topic is probably passe` around here... :)
I can weigh in with some practical/historical experience from VisualWorks land, where they originated.
1) We use them more and more. But judiciously. What they are really good for is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.
Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.
2) I push, at ever juncture I can, the term <tagged methods> and <method tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).
3) You can get carried away with <method tags>. It's tempting to grow little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...
4) History repeats itself, I think I wrote a post along these lines, about 3+ years ago. I've slept since then tho, so I'm not sure.
-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval