To generalize a bit: a lot of the things that might seem odd to non C++-programmers are perfectly natural to C++-programmers.
It's not often that I hear that C++ is too narrow. Being able to add new operators and changing the way the type checker works both seem like niche things and something that is more fit for a research language.
That said, I very much agree with your point--the middle ground between those two modes is cluttered and there lies madness.
The problem with the new features of C++11/14/42 is that they are never going to remove the existing jank of the language; these folks don't seem to understand--or want to understand--that there is never going to be a magical fucking tabula rasa onto which they'll scrawl their code, unless they want to rewrite all the things from scratch (which may actually be a good idea).
That being the case, they're going to get run circles around by people who either stick to existing jank and libraries or use a language with a better set of batteries and more flexibility (Ruby, Python, etc.).
The power and speed of C++ is not worth the difficulty, usually, of finding people who can use it properly.
In my honest opinion, C++ needs to separate low level concerns from high level constructs. How variables are captured in lexical closures is a very low-level concern, but lexical closures are a high-level construct -- by mixing in such low-level details, the overall utility of closures in C++ is reduced. This is made even worse by the fact that the programmer must manually maintain the lexical environment of the closure -- and the new "smart pointers" are only marginally helpful, not nearly as robust as a modern garbage collector (which can, oddly enough, improve performance).
C++ could be a really great language if these things were better separated. I write my code in Lisp, and when I have low-level needs I usually have to write some C code and use an FFI. It gets the job done but it is awful to debug and there is a performance hit. C++ is in a much better position: you can write low-level code, or you can write high-level code, or both, and no language barriers need to be crossed (reducing costs in various places).
"As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position to say."
Well, aside from what I mentioned above, I can give you one more: extending the language. You have a few narrow ways to do it, and then you are just stuck. Operator overloading is great, but what if you want to add a new operator? What if you want to change how your type checker works, so that you can have a dependent type system? There are a few hacks that people can do with templates, but on the whole adding a new feature basically means rewriting your compiler (see e.g. what it took to get support for lexical closures), and C++ compilers are pretty hard to write in the first place. This is something of a Lisper gripe, though there are a few languages beyond Lisp that allow programmers to add new syntax or semantics.