I wanted to ask this very question, to see how many companies were actually practicing TDD.
In the 11 years I've been programming professionally only the last two organisations were even aware of TDD (that spans almost 5 years mind, before which time TDD wasn't as popular as it is today). I'll cut to the chase and answer your question before digressing into my sales pitch for TDD :)
At the last company I worked for (online academic publisher of humanities and science collections), we knew we needed to practice TDD but we never quite got there. In our defence we had a 250k code base, so adding tests to an untestable code base of that size felt insurmountable (I feel guilty typing that now!). Even the best of us make mistakes.
Anyone who's done even a small amount of TDD knows how painful retrofitting tests to brown field untestable code can be ... The primary causes are implicit dependencies (you can't pull all the levers to assert results from code - you can't mock scenarios) and violation of the single responsibility principle (tests are complicated, contrived, require too much setup and are hard to understand).
We temporarily grew our QA team (from one, maybe two people to half a dozen or more) to test the platform before any release. It was hugely expensive time wise and financially, some releases would take three months to complete 'testing'. Even then we knew we were shipping with issues, they just weren't 'blockers' or 'critical', just 'high-priority'.
If you've a years commercial experience you'll appreciate that every company asserts critical tasks, and then invents a higher priority level above that, and most likely one above that too - especially when someone from above is pushing a feature/bug fix. I digress ...
I'm happy to report I'm practicing TDD in my current company (telecommunications, web and mobile app development house), coupled with Jenkins CI to give other static analysis reports (code coverage being the most useful after asserting the test suite passes). The projects I've used TDD on are a payment system and grid computing system.
The sales pitch ...
It can often be an uphill struggle justifying automated testing to non-technical team members. Writing tests does add more work to the development process but ... the time you invest in testing now, you'll save in maintenance effort later. You're really just borrowing time. The longer the product is in use, the greater saving you'll make - and it'll help you avoid the big rewrite.
Test first means you're coding your intent first, and then confirming your code fulfills that intent. This provides focus and distills your code to do only what is intended and no more (read no bloat). It's an executable specification and documentation at the same time (if your test is well written, and tests should be as readable/clean as your system code, if not more!).
Non-programmers will (often) not have this insight and so TDD doesn't hold much value for them, and is seen as disposable shortcut to an earlier release date.
Programming is our domain, and in my mind this makes it our responsibility, as professionals, to advise on best practice like TDD. Not for project managers to decide if it's done to reduce development time, it's out of their jurisdiction. In the same way they don't tell you what framework, caching solution or search algorithm to use, they shouldn't tell you if you should be employing automated testing.
In my opinion the software development industry (on the whole) is broken at present, the fact that having tests for your software is NOT the norm.
Picture this in other industries: medical, aviation, automobile, cosmetics, soft toys, alcoholic beverages etc. I asked my fiancee to name an industry where they don't test the product and she couldn't!
Perhaps it's unfair to say no testing occurs because it does ... but in companies without automated testing, it's very manual/human (read clunky and often error prone) process.
One point I would contend in your question ...
They usually wanted development started immediately, or after a short design stint. More akin to Agile.
Being "Agile" doesn't prescribe proceeding without tests, the first member listed on agilemanifesto.org is Kent Beck, the creator of XP and TDD!
Two books I would highly recommend if you're interested in TDD, or just haven't read them and are a keen programmer (that's everyone reading this right? ;)
Growing Objected Oriented Software Guided by Tests
Clean Code - Robert C Martin ("Uncle Bob") Series
These two books compliment one another and condense a lot of sense into few pages.
Thanks for asking this question :)