That's more a matter of experience and attitude -- even simple things like reference types are nice. Also, templates offer a lot of abstraction power that can be used to model the hardware nicely, without sacrificing efficiency.

Many embedded programmers come from a background that doesn't expose them to those sorts of ideas though.

Can confirm, C++ has some nice features which I'd even like without malloc. OTOH I'm already horrified at the code quality problems pretty much every embedded shop faces. C++ would only make this matter worse.

As a software inclined embedded guy I also often think of what would be possible if we switched to C++. But then I think of what's probable.

Even without dynamic memory there's ton of useful things:

Namespaces, References, collection types (std::array, string_view, intrusive containers, etc.), RAII (release mutexes at scope ends), strong typing, proper encapsulation, interfaces, etc.

In general tools for constraining hardware complexity like namespaces and encapsulation are a lot less important for the project sizes where you're typically working with embedded systems. For the rest they mostly provide some benefit but that's offset by the danger of a move to a much, much larger and more complicated language in an environment where many people writing code are primarily EEs and most C++ answers they Google will provide solutions inappropriate for embedded development. And I say this as someone who was one of those EEs when he started out.

RAII is absolutely killer. Managing real time priorities with lock_guards so that you can never forget to drop priority will win over almost any grizzly old firmware engineer.

There is still a lot to be gained by strong typing even in projects where everything is statically allocated.

Many people need in memory databases and linked lists (or binary trees) to hash information and sort it.

There's a case to be made for an OO style program where I create an object and give it a chunk of memory to manage a B-tree, so I can keep my memory from being fragmented, but using C++ for that is serious overkill.

I can see people arguing for object oriented over procedural.

As I type that, I realize I've recently learned to love Go, so maybe it is my bias.