The same is true for C++, and early reaction was similar: hey, we don't need high-level languages anymore! But after a few decades with C++ we've found that the burden manifests not when writing the program but when maintaining a large codebase over many years in a team whose members change over time.
I've used C++ since the 90s and it's only ever been presented as a Serious Language for Real Applications. I feel that until recently, C++ stood alone and there were almost no serious threats to its position, except maybe Java. If you were planning on writing commercial programs (or even more so a collection of programs) that have good performance and huge featuresets, like an operating system or a browser, what else could you have possibly used?
I agree that in practice maintenance has been pretty bad for C++ programs, but I think I understand the kind of reasoning that led so many organizations to pick C++, even if I don't agree with it. It was not about ergonomics or productivity, but about control. The language grants an unprecedented level of power to a small group of elite programmers inside every organization, who author the standard library and headers that all the other programmers use. They're building the smart pointers, the memory allocators, the IO libraries, and the build systems. It's imperative (to them) that their good decisions don't get snowed under the mountain of application code that the more mediocre programmers are going to be producing by the truckload. So it's important to have powerful encapsulation, compile-time checks, and metaprogramming capabilities. Doesn't matter how safe by default or how slow it all is, because the elite add guarantees themselves through the abstractions they write, and don't have to compile a full application very much, if ever.