It's reasonable to assume that compilation times can go down if you decide to forego compile-time features (i.e., templates).
However, C++'s standard library is a productivity blessing. I'm not convinced of the advantage of replacing it with ad-hoc components that may or may not be buggy just because you want to shave off a few seconds of each build.
More often than not, all you have to do to lower a double-digit percentage of your compilation time is to modularized your project, and follow basic principles like not have includes in your interface headers. This alone, along with PImpl, does far more for your compilation time than well-meaning but poorly thought-out tradeoff decisions like not using the STL.
There is no way to use the STL and other template code and still have reasonably sized projects do full builds in seconds. That's just an empirical fact. The only way to get C-like compile times is to essentially write C, with minor additions.
If you genuinely regard the standard library as a productivity blessing I'm sure this looks like an unreasonable tradeoff. I would be very surprised to see someone advocate writing "Orthodox C++" solely for the compile times. Most of us who write code like this do so because we don't find value in the STL and regard templates as an extremely poor tool for their ostensible purpose. The compile times are just a bonus, albeit a very pleasant one.
In truth, the divide isn't between people who prioritize compile times over any other consideration and people who don't. It's between people who see most of the language features of C++ as valuable and people who see them as mostly unhelpful. Personally, I like operator overloading for math and SIMD types, function overloading for less verbosity, namespaces and a bit of constexpr for convenience. The rest I'm quite happy to do without, so there isn't much of a tradeoff to make.
I read the article. The author noticed that MSVC's STL has slower iterators in debug mode, because it does extra checks. Instead of reading the manual and turning off the extra checks and/or reading the manual and turning on some optimizations in debug, he re-wrote it in C, which doesn't have the extra checks to begin with, and was happy because it compiled faster. All the optimizations in release mode came from better algorithms or allocators.
I can't say I'm particularly convinced. Yes, C++ debug builds can be slow. For most of us, that's ok. If it's not, make your "debug" build configuration a release build with the optimizer turned down (but not off) and incremental build enabled. Preprocessor definitions, symbol generation, optimization, and incremental build are all independent settings - if all you need from debug is symbols, incremental builds, and the inliner turned down (so stacks are retained) - then configure your compiler that way.
However, C++'s standard library is a productivity blessing. I'm not convinced of the advantage of replacing it with ad-hoc components that may or may not be buggy just because you want to shave off a few seconds of each build.
More often than not, all you have to do to lower a double-digit percentage of your compilation time is to modularized your project, and follow basic principles like not have includes in your interface headers. This alone, along with PImpl, does far more for your compilation time than well-meaning but poorly thought-out tradeoff decisions like not using the STL.