"Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples."
And that's really part of the problem. Too many people who vehemently defend C/C++ against managed language performance are doing so having just written or run a brief managed language application and said "See!".
But it's not a fair comparison, talented C++ developers can write good, performant C++ applications because they understand the language, they understand the compiler, and they understand how it all interact so that they can write that performant code in the first place.
Managed languages aren't magic, if you want an optimised application you still have to understand the platform - in something like .NET that means understanding GC generations, the impact they have, what should reach gen 2, what shouldn't pass gen 0, and how to make sure it doesn't pass gen 0. Unless you understand your runtime, be it the CLR, or the JVM as well as you understand your C++ compiler, you can't rationally compare the two and claim one is better than the other.
That's where you're going wrong - you're suggesting that code written to be optimal in C++ should be inherently optimal in Java, or C#, and that's a completely false assumption. It's also why you're right about something - that the GP is completely wrong. Learning C wont make anyone a better programmer in a managed (or even interpreted language), it's a different platform, and the rules are different. Probably what someone means when they say they should learn C first is actually that people should understand their platform first - they should understand the intricacies of the JVM, or the CLR, or their C++ compiler, or even the underlying OS and hardware. I disagree though, I think you learn those things best through programming, though some people certainly never really learn them, and that's a problem.
"Among the more significant differences are that C++ compilers are extremely good at optimizing, and C++ code generally compiles down to better cache-coherent structures than other languages. The difference is in the language itself, which adheres to a zero-cost principle, in that you don't pay for features you don't use. A lot of C++ abstractions are eliminated *entirely* at runtime, and are only used to protect the code's integrity during the compilation phase."
But even then they're not as good at optimising as JIT compilers, simply because additional compile time information always inherently means better optimisations can be performed - this is an inescapable fact, the more information a compiler has, the better it can optimise, and a JIT compiler on the specific execution machine will always have more information than a C++ compiler compiling for a target architecture (rather than a specific machine) - the JIT compiler has full hardware and OS information (and not merely rough architectural information - something pretty broad like x86, or x64), and it can also gather runtime information to optimise around runtime patterns. Yes, C++ compilers have gotten very good over the years, but unfortunately it's an inescapable fact that JIT compilers will always inherently be able to do better - it's just the nature of the beast, and there's no getting away from that bar C++ applications being able to self-optimise at installation or runtime.
"We were told for years that native-equivalent performance was just around the corner or even already here, and it just never really happened outside of small, contrived benchmarks."
It's been here for quite some time, but if developers don't know how to achieve it then it might as well not be. Great developers are doing great things in managed languages - many of the big boys have those staff on board, companies like eBay, Amazon, Google, and just about all the banks et. al. but similarly they also have great C++ developers doing great things too.
But the thing is, that's not really where the managed advantage is, it's a reasonable question that if you have to be a knowledgeable expert to reach native performance on a managed stack then why not just be a knowledgeable expert that is competent enough to do it in C++? I agree - and IMO the strength of such languages is in the fact that amateur to moderate developers can write better code faster in them than they can C/C++. So whether to use them is about as you say, using the right tool for the job - if it's just an experienced high end developer or team of working on the project then you can probably go full C++, if you've got a bunch of juniors or moderates in the mix then you may be better throwing in that managed safety net and let the expert focus on performing macro (i.e. being active in the overall architectural design), and micro (i.e. optimising algorithmically the code of other developers) optimisations of the overall solution. There are also the more obvious reasons - sometimes it's just a question of what the client has asked for.
So I mostly agree with what you say, regarding using the right tool for the job, and regarding C being a poor language choice, but I don't think you have enough depth of knowledge of any managed stacks to write code necessary to fairly test and understand why managed code can perform - you need to invest as much time in learning how to write optimised JVM or CLR code by understanding those stacks, as you probably have invested in learning how to write optimised C++ code.