Changes to the language should not be done just to attract more users. This is especially true if these new users would be today's PHP, JavaScript and Ruby users. The C++ community is much better off without these kinds of programmers.
It's much better for people to use C++ when they realize that they need the powerful functionality it offers, rather than dumbing down C++ in a way that'll make it attractive to less-skilled developers.
Relevant anecdote: I know a number of C++ programmers who said they would use Haskell / Python / etc. to "prototype" a system, then switch to C++ when they needed what C++ has to offer. None of them made the switch back to C++ and their "prototypes" became finished products.
This is because the vast majority of the time people's claims of performance requirements are complete BS. If you're writing true system software (an OS kernel, a database, an MQ system, etc) then shaving microseconds is going to matter because 10s, 100s, 1000s or even more applications built atop or using your code will be leveraging the minor gains you are creating. If you're building "Misc App X" then it's probably not going to matter.
Another thing I noticed is that of those people who do have serious performance requirements (OS kernel etc.), many choose C over C++. We all know what the most famous example is. I have no experience in this area. I wonder if there is any data on the use of C vs. C++ vs. other languages like Go in that realm.
Keep in mind that there are also many cases that are the opposite of what you describe. I've worked with many systems that were initially implemented in a non-C++ high-level language, yet the developers had to go back and start incorporating C or C++ code at some point for various reasons, if not re-writing the entire system in C++.
The hybrid approach that Python allows for is extremely powerful, given how it makes calling down to C and C++ code from Python code quite trivial, or embedding a Python interpreter within existing C or C++ code.