You make a great many assumptions about the libraries that I use, and how I use them. :)
There are people that use templates to their full ability, and do not bat an eye at the resulting template errors or weird code issues.
Most of the times I see people using templates I can't help but wonder "Why the heck aren't you using a language that fits your problem better?".
They're cool features, sure, but notice that the days of C++ as a practical get-shit-done language are pretty much over. There's not really anything I'd consider C++ best or even second-best at if you can use other languages.
I'm not sure why you say I make assumptions as to what libraries you use. In fact, I thought I made it apparent that I made no such assumptions, given that I stated both possibilities: 1) You use libraries that are powered by meta-programming (making it good for you, ergo good that it is part of the language). 2) You don't use libraries powered by meta-programming (doesn't matter, a huge c++ user base do, ergo good that it is part of the language).
If you belong to either of 1) or 2), it doesn't matter whether or not this feature is possible, you can choose not to use the libraries, and you can choose not to use meta-programming features.
Could you share an argument as to why you feel a language shouldn't have features that you don't have to use?
If you don't use STL, boost, QT, or pretty much any C++ library I can think of... do you write everything from scratch?
As for when C++ is "best" or "second-best", these kind of questions tend to lead to opinion-based arguing, rather than constructive discussion. I'm definitely not interest in the former, so I'll just give you the general objective consensus of the programming world: C and C++ are used when performance matters. C++ allows more abstraction without a real runtime cost.
So, framing the question as "a language shouldn't have features that you don't have to use" is kind of obfuscating the issue. The answer to that, for example, is of course not--as the Python folks are finding out (or celebrating, depending on how you feel about that way of thinking).
The problem is that the vast majority of languages have some features that you don't use, and even if others use them then things still generally work out okay--you can hide it away.
C++, via operator overloading, exceptions, backwards compatibility with C and its problems, templates, function overloading, and all manner of other things, is simply too large to be trusted. I assert that it is so difficult as to be practically impossible to ensure that, if you rely on third-party code outside of your direct control or the language spec, you are writing safe, performant, bug-free, and maintainable C++ code. C is magnitudes simpler, and people still manage to fuck that up.
Everyone bandies about the performance of C++ and the whole only-pay-for-what-you-use aspects of it, but in the fast majority of cases that's simply not important from a business or project standpoint. If you're writing numerical code, for example, why not just use the hyper-optimized compilers available for Fortran? If you're writing tight embedded control code, why not just use assembly?
Sure, I've had a friend that worked on the CMS at Cern and they used some unholy pile of C++ dating back 20 years and that worked well. I've known a bunch of people doing bioinformatics and they all write/copy/paste shitty C++ and get faster results than their semi-legible Python or MATLAB.
That said, all of those use cases are academic, which is maybe the last place where performance even matters (arguable in and of itself). You might claim "but but but games!" and then you'd be wrong again, because a great number of games are written using super-slow scripting engines and terrible C++ codebases. Mike Acton, giving a talk at a conference this year, pointed out that there was no compelling reason to use C++ over C because the OOP features fall on their face in a high-performance environment.
It's just a bad language. It was useful once, it's occasionally useful now (if you must, which you usually don't), but we really should just move on to new things.
Its OOP features are poorly thought-out, its performance with the standard library is pretty bad without modification for certain use cases, its learning curve is absurd, its growth is unbounded. Just let the thing die.
To answer your question about rewriting things:
We did write a lot of things from scratch, and spent years battle-hardening them, because we didn't want to deal with the (at that time horrid) development overhead and philosophical issues of Boost. STL was fine until it wasn't due to some cross-platform issues. QT/POCO are cool in their own right, but didn't match our use case.
There are people that use templates to their full ability, and do not bat an eye at the resulting template errors or weird code issues.
Most of the times I see people using templates I can't help but wonder "Why the heck aren't you using a language that fits your problem better?".
They're cool features, sure, but notice that the days of C++ as a practical get-shit-done language are pretty much over. There's not really anything I'd consider C++ best or even second-best at if you can use other languages.