I'd phrase it differently, C++ was a set of power-to-performance trade-offs that were optimal in the 1990s.

Time has moved on.

More importantly, a typical 1990s C++ dev was likely someone who learned assembly, then C or C++. Meaning they already knew how to control hardware / memory allocation, and C++ was just a new set of abstraction tools. It was a step forward for them.

To modern devs, C++ is a step backwards. And a tough one at that.

Actually, C++ was rather poor in the 1990s if you ask me (albeit still very usable). Time has moved on - but so has the language. Its implementation tradeoffs were much better IMNSHO after 2011; but it wasn't there yet. And it still isn't! It has a lot of warts that have to stay for backwards compatibility (which is a design goal); and then, it has annoyances I can't believe are not yet addressed (like - where is my 'restrict' keyword, damn it?!)

Anyway, your view of the 1990s devs is incorrect. Almost no programmers who took up C++ learned assembly first (and few ever learned assembly). I believe most of them learned Pascal, or C, or scripting languages like Perl or Tcl or Unix shell scripts. Some may have learned Lisp or some ML variant as their first language, or Fortran 90. They didn't take a step back, they switched to a different set of language design goals and tradeoffs, and found it, well, serviceable.

It is indeed a bit peculiar that the language has had this much staying power. For C, it's much more understandable - because C is such a small and simple language (and one which, as you suggested, often feels like a bunch of syntactic sugar over PDP-7 assembly). But C++ is big, and has its baggage and warts and flaws. I think it's probably because it's been able to adapt and stretch just enough under the influence of trends in programming languages, for people not to ditch it for something new. Maybe Rust will change that; but - C++ might very well "eat its lunch".