I think this is a more of a case of wrong tool for the job. For example if i have a fairly static mail server configuration then it could best served by stable - I get security updates back ported but I won't have significant changes in the underlying platform whipping the carpet from under my feet.
Choosing stable for say the website may not be such a good fit though - the website is permanently in a state of flux due to having money and developer time invested with a lot more vigor, introducing new technologies to the stack, I'd be better deploying testing or more likely unstable under that stack.
For all I love Debian, the naming scheme has cost me many hours explanation to senior ops management over my younger years!
All that said, there is also the valid ops concern about developers introducing unproven tech just because it's in fashion even though there is no business, operational, architectural or even development advantage to be demonstrated or even hypothesised from it.
Its not fun for anyone when you have A team of developers with their dummy's out the pram because you wont open any to any routes on the dmz firewall so they can use some new sexy message queue when any one of the well behaved, well proven, stable alternatives would offer the same advantages.