I would like to add to this discussion that I have a feeling that a lot of the quoted/cited statements are interpreted as a rigid ‘gospel law’ rather than a guideline whose exact rigidity and details depend on where it is used.
Dont make choices based on what someone else said about the situation they were in, but based on a comparison you make between the situation they were in and the situation you are in.
Personally, I do not write tests during a hackathon with a strict deadline. I do not write tests when creating a Proof-of-Concept. Tests restrict/slow down redesigning of the system which in these cases is vitally important to be able to quickly do.
I do write tests once a system is approaching a presumed ‘stable’ state, mostly to prevent regressions in the future. A certain dose of regression tests are also really good to keep your code from breaking functionality when working together with multiple people.
I do write feature/integration tests when requiring to follow a strict set of specifications/requirements (c. f. gherkin, it is super cool ); mostly to be able to agree with the other party about the details of the specification exactly.
I write unit tests mostly as doctests to explain, in a library or business logic code, to other devs (and, importantly, myself) how stuff works and fits together. This is also the main place where I sometimes work test-first, when I already know how I want something to look but have yet to write the implementation.
I write rigorous tests and possibly type-proofs if (and only if) writing important systems that are vitally important (like when a crash would be life-threatening or cost thousands of dollars) or when the system will be impossible to change in the future (like when writing Smart Contracts).
There is no silver bullet in choosing a testing methodology. It really depends on what you are doing. To answer the original question: I would probably not do Test-first development when there are strict deadlines,( but maybe I would based on other requirements of the project).
Oh, and as a side note: avoiding strict deadlines will probably improve the quality of your applications. Of course, educating managers is hard .