That's a weird thing to say, because C++ has better high-level abstraction facilities than any other mainstream language today.
Also, why limit ourselves to "mainstream" languages? Once upon a time C++ was not mainstream. Why should we shy away from Lisp, OCaml, or Haskell just because they are not popular? In every discussion about C++ and its technical ups and downs, someone points to its popularity, as if that were some kind of justification. The history of computers is overrun with examples of popular-but-inferior technology.
(edit: C++'s main deficiency against C# and Python is its lack of a reflection system. Against Haskell, C++ is well known for being similar, but templates in C++ are more flexible and less constraining than Haskell's type system features -- for example if you want to overload + you don't have to buy into the entire Num typeclass.)
Really though, my big issue with C++ is that the high-level features are bogged down by low-level details -- if I wanted to deal with low-level details I would not be using high-level features in the first place. Why should I have to manually determine how to capture variables in a lexical closure? Why should I have to manually declare "virtual" inheritance to deal with the multiple inheritance diamond? Why are destructors not virtual by default? Why are string literals still pointers to character arrays, why are arrays still not bounds-checked, why are integers still fixed-width (and why are integer overflows not reported as errors?)? Yes, these things all make sense sometimes but in most cases they are the opposite of what you want -- you should have to write more code to get this behavior than to avoid it.
I disagree here. First, the nature of the language is no excuse -- I am criticizing the nature of the language to begin with. Second, in this case, there is a sensible default: always capture by value. If you need or want to capture by reference, create a reference and capture that -- which is already what people have to do when they return a closure and use smart pointers to maintain the lexical environment.
"The other questions, you know the answer to, and the answer is very obviously performance or compatibility with C (or just bugs in the language)."
Except C++ does not maintain compatibility with C, and "performance" is not an excuse either. If performance is a concern, create a keyword to disable default behavior; e.g. if you want to not have a particular destructor be virtual, then there should be a keyword for that. Even compatibility with C is not an excuse -- already the extern "C" syntax is used to disable the name mangler, so why not go all the way and have it also disable things like array bounds checking and creating string objects for string literals?
Basically, C++ is a language that makes unsafe code easier to write than safe code; this is the opposite of what a high-level language should do.
All the things you want would incur a performance penalty were they the default.
Edit: Also, I don't know much about Lisp, despite being a bit of a Scheme weenie in the past. When I try to think about whether I'd like to implement some hypothetical project in Lisp or C++, the most important difference between them seems to be garbage collection. It's more realistic to ask whether I'd rather use Lisp vs. Java, or Lisp vs. Scala, or Lisp vs. C# or Python or Ruby, than C++, because garbage collection is a big issue that makes it difficult to compare them by some notion of how it would feel to use the languages.
I have a hard time evaluating whether macros are really that useful. Whenever I see people give examples of using macros, usually it's just superfluous, something that could be done a bit more verbosely without macros in a language like Python or Ruby, or done a bit superiorly in something like Haskell. And if it were a situation where macros were very useful, all I can think then is (now let's pull some anti-macro tropes out of the hat!) how debuggable is this? And would it really be that hard to solve the same problem in one of the other languages?