I think that the “we can go quicker by not testing” is a fallacy. If you do TDD right it will make you quicker, not slower in the short term. Not just the long term...
Furthermore, I would ask you to name the contexts in which you believe TDD to be better in the short term. Things differ when a lot of critical and non-trivial data-modifying code exists compared to an interface which changes requirements by the week, to name two extremes on opposite ends. Things also change when the codebase grows beyond proportions for the devs to actively manage within their heads, or when TDD starts serving as a way to document your codebase for new people coming in. There are plenty of situations one can imagine these conditions not being present, and where a developer with a relatively high degree of correct output would slow themselves down with TDD, the same way some people need to overhead of pulling out their calculator and confirming the answer while someone else calculates it in their head without confirmation.
While I won't deny TDD can, or at least should, have benefits in the long term, it is fairly extreme to claim testing is almost always better without the proof to back it up.
I personally write significantly higher quality code, faster, when I spend a few hours thinking through the problem in a document beforehand. One of the things to think about is how to best test it, and most of the time that means a unit test. Knowing that when starting to write the code influences the interfaces and structures that I come up with.
Anecdotally, one recent project at work required writing a relatively small, 100% self-contained program with significantly less serious / more silly requirements than the typical type of code I write. I initially didn't plan on writing any unit tests, and about 500 lines of code later I had the program working 99% correctly. There was one bit of overtly complex code that was a bottleneck, though, and it made the overall program 30x too slow for its purpose. The fix was to replace a conceptually simple iterative solver with some brain-melting closed form equations. About 8 hours of iteration and manual testing later, I was pretty sure I had correctly handled all the edge cases. My brain was melted, though, and I couldn't even remember half of the edge cases I had encountered. It took me another 20 minutes to write a unit test that compared the output of the iterative solver with the output of the closed-form solver. Had I done that from the beginning, I probably would have saved 4 hours and not melted my brain.
The thing with writing code and testing is that, if you're in the habit of it, unit tests typically take a less-than-linear amount of effort vs. writing the actual code. Once you have tests, they decouple code complexity from development and maintenance, and you can therefore achieve a more sophisticated overall solution than otherwise with the same resources. If you don't develop testing as a skill, though, then those benefits don't materialize because you're inefficient at it. So, while it may be true that a given project or team wouldn't benefit from prioritizing test coverage, it's seemingly due to lack of expertise rather than a lack of obvious benefit. If I'm working on a home improvement project and my toddler wants to help tighten a screw, I wouldn't hand her my impact driver and expect her to successfully use it let alone not hurt herself, despite it being an unambiguously more efficient tool for driving screws than her little green plastic hammer.
I find a lot of value in unit tests for isolated logic testing and in functional tests for end to end testing. Still that leaves a lot of code in a modern web application (like stackoverflow) where I find tests don't provide enough bang for buck.
If performance is a main goal, then surely TDD with performance in mind will give you a better advantage