Using backticks permits you to use alternative characters. In query writing it's not such a problem, but if one assumes you can just use backticks, I would assume it lets you get away with ridiculous stuff like
SELECT `id`, `my name`, `another field` , `field,with,comma`
Which does of course generate badly named tables.
If you're just being concise I don't see a problem with it,
you'll note if you run your query as such
EXPLAIN EXTENDED Select foo,bar,baz
The generated warning that comes back will have back-ticks and fully qualified table names. So if you're using query generation features and automated re-writing of queries, backticks would make anything parsing your code less confused.
I think however, instead of mandating whether or not you can use backticks, they should have a standard for names. It solves more 'real' problems.
count
,type
,table
or similarcount
,type
, andtable
. Those are awfully ambiguous terms and in almost every case those names could be improved to be more specific. Naming your columns things like that is also dangerous and a potential source of errors, as you never know when someone might forget to add the backticks or not realize they have to. I think it's better practice to just avoid using reserved terms as column names.