C++ isn't necessary in many business contexts, and can result a worse business overall outcome than alternatives. If it's a harder tool for people to use, and the use of the hard tool isn't necessary, why would you use it? Why not use an easy tool? Especially if the easy tool means more people can wield it, so there's a wider labor pool to draw from, or a reduced error rate from tool-difficulty-induced defects.
Indeed, many businesses correctly decide there's no benefit to using a difficult tool that isn't required, and choose an easier tool that produces a better business outcome.
e.g. suppose you're a non-tech enterprise (bank, utility, etc) and you need to build a bunch of backend web services to support your internal operations. If you decide to implement them in Go, which is arguably a domain specific language for building web services, then you can probably deliver the project by hiring a bunch of fresh grads and putting one intermediate to senior programmer in place to lead the effort, even if no one has any Go experience.
arguably if you try to deliver the same business outcome in a random enterprise context using C++, a project team will likely have a far more difficult time getting basic HTTP / TLS server stuff in place, and if there's lots of rookies on the team, they'll keep making foot-gun memory error mistakes.
Sure, maybe if it was built in C++ by highly senior engineers, and subjected to a thorough QA process, you could end up with a system that's much more efficient at runtime than what could be cobbled together by less experienced engineers with an easier language and a good standard library. But in most business settings efficiency isn't the bottleneck, it's delivery speed and then maintenance costs, which are driven by staffing and how expensive it is to change the code each time the requirements change.