Single-pass is a bit of a gimmick. It requires programs to be written sequentially in a strictly "bottom up" way, so that forward references to parts of the program that have yet to be defined are rare enough that they can be marked specially (e.g. as with C program headers).
It's also largely irrelevant if you want optimized code generation, especially across multiple procedures, since that requires you to read abstract representations of the code into memory and deal with them globally which is the opposite of single-pass compilation.
How often do you need highly optimized cg during development? Unless I'm working on games, 99.9% of my time (even on highly performance-critical software) is spent on evaluating debug builds with 0 perf requirements - because I need to implement it correctly first, and make sure tests are passing.
I think it's uncontroversial that most fast, statically compiled languages benefit greatly from quick debug builds. It's just that very few of them are designed with this in mind.
I think I have made the argument above that the feasibility of single-pass code gen boils down to how the program is structured, not so much the language design itself. Perhaps current compilers should be reworked to generate code about as quickly as TP did, if optimizations are totally disabled and the code is written to eschew unresolved forward references. But I'm not sure there would be much of a point. And you would still have many language features where going back and performing a second pass over what was previously parsed (and perhaps codegen'd) just can't be avoided.
It's also largely irrelevant if you want optimized code generation, especially across multiple procedures, since that requires you to read abstract representations of the code into memory and deal with them globally which is the opposite of single-pass compilation.