What usually happens is that the code gets unreadable/unmaintainable quickly and is still a complete unoptimized mess at the macro level.
Once you realize this you don't need C++ for most application domains. And for the domains where C++ matters you also realize you'd be better off in C with a scripting language on top.
And even though it was one of the languages I enjoyed most using after Turbo Pascal and I even gave C++ classes at the university, I am a firm believer that if Java, VB.NET and C# had been fully AOT compiled from day 1, just like many other alternatives that used to exist, C++ might have not taken off as it did.
The rise of VM languages, with other AOT compiled languages fading away and rise of FOSS written mostly in C, made C and C++ the only languages we could turn to when the performance was lacking, thus arriving at the actual situation.
As for using C with a scripting language, without the safety of strong type checking, real enumerations, support for arrays and strings, no namespaces, no RAII, new/delete instead of malloc()/free() and many of safety improvements from C++ over C, that is not something I will ever advise.
I already did that once with Tcl for two years, no need to repeat it.