It’s a general Unix thing. It’s a general Linux thing. It specifically applies to the Linux kernel, and has been used recently (2.6.whatever) to defend choices about the wretched scheduler implementation.
Now, it’s nice that you can swap things in and out, which is what “mechanism” implies. (Obviously I’d rather not have to do this via the virtual fs of /proc, but still.)
But it’s evil and nasty and downright disastrous, from an architectural point of view, that you completely disregard policy.
This is how X came to acquire a dozen different widget sets, all disjoint from the others. (There are other X consequences: see Unix Hater’s Handbook for details.)
This is how Unix, in general, came up with not one, not two, but something like six or seven shells. Every one of them with completely unparseable languages. Which is just the start, really: try using a single common command on any of them (go on, I bet you can’t remember the ksh switches to ls).
This is how the Linux desktop ends up with not one but two major IDEs (OK there are more). This is how, when I come to look up a FOSS alternative for Visio — just basic, mind, I don’t care about the bloat — there is no such thing. Whatever I choose is closely bound to a mechanism, not a policy. And guess what? It’s a totally arbitrary mechanism that changes at random and is unsupported anywhere else.
MechanismNotPolicy™ sounds hifalutin’ and the cynosure of all CS Majors’ eyes, but I’m telling you, it’s not.
It’s a suppurating sore and it’s criminal neglect of responsibility and it just will never work.