So, #1.1 was all about the "business" - people defining requirements, and how these can cause issues. #1.2 is just a short entry about the underlying statement I was trying to make in the original post:
Anti-pattern: Where inexperienced/misguided developers keep on testing where it's not realistic or financially astute to do so, thinking that's what TDD is, and thinking they're "adding value". As we all know, that's not what TDD is. And it's something we should try to avoid by coaching, mentoring, and working closely with development teams; helping to give them ways of judging the value of any piece of work.
It's all too easy to work with a group of savvy technical people that get TDD, and not be able to see how it could go wrong. If you try and scale this across an enterprise where some people just don't get it, and the support isn't there to keep things moving in the right direction, things can, and do go wrong.