I'm not sure that's true. C's simplicity helps it out here.
Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.
But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.
C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.
I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.
Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.
C's supposed simplicity is wholly a mirage. "Limited" would be the accurate description.
Everyone's chief exposure to complexity is the code written in the language, where the complexity comes from the problem domain and everything it takes to wrangle that complexity with what the language has to offer. By that measure, C's sharp limits mean that your exposure to complexity is much greater in a C program than in a C++ program.
Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.
But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.
C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.
I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.
Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.