How are they broken?
It's not that they're broken in themselves, it's that they've been added to a language that can't support them properly. People say, oooh, you must write exception-safe code. What they're saying is, there's a property the code needs to have, which a compiler cannot test for, which you can't even easily unit-test for. And without this property -- exception-safety -- the code is unsafe. (It's not the code that throws or catches exceptions that you need to worry about: it's routines whose callees might throw and whose callers might catch. Those routines have secondary control flows through them, ones you can't see, but which need to be correct for the program to be safe.)
It's not an innovation of the TDD community to say, that if something in your code isn't tested, you can't swear it works. In particular, you can't swear it will continue to work when future maintenance occurs. Because exception safety can't be "defended" against future breakage, I don't think you can hand-on-heart deliver C++ software written with exceptions and claim that it works.
I'm not against exceptions as a programming technique: I think they work great in managed languages such as Python, Java, or ML. In those languages, it's not possible to write code that isn't "exception-safe" in the C++ sense. That's where exceptions belong. Throwing exceptions through unmanaged code was a brave experiment on C++'s part, but it's a misfeature, and I've got more confidence in codebases which forbid that (despite whatever problems they have with two-stage initialisation) than codebases which don't.