It's easier to start from a GC'ed language, and use escape hatches when you need them, then to start without GC and then realize that your program has become a mess because you don't have it.
Many GC'ed languages have such escape hatches. Those that don't, well, don't start writing performance-critical code in them would be my recommendation.
And also, do not miss his point about reference counting just being a form of GC. "Manual memory management" isn't really a thing that exists, there's a whole suite of memory management techniques and alternatives, and it's easy with something like "C++ with ref counting" to actually be experiencing the worst of all worlds (all the work of "manual" memory management with all the disadvantages of GC) if you don't deeply understand what's really going on with your memory.
Funny you mention the "worst of all worlds scenario" because that's exactly what I was thinking about your advice to start with a GC'd language and then escape for performance critical (which usually means huge heaps btw) parts. This plan combines you all the flexibility, predictability and reliable latency of managed VM systems combined with all the safety guarantees of a manual memory managed system.
Read my whole first sentence again. Carefully. I think it does not say what you think it says.
Furthermore, I still don't think you got the point that there is no royal road to perfect memory management. You can't just say the words "manual memory management" and pretend you've solved the problem, or indeed, that you've said anything at all. Many of the same "manual memory management" techniques that you might use are still readily available in "garbage collected" languages. It's not a boolean, it's a rich space. And thus, I stand by my first sentence.
Can't tell whether joking or serious. I guess my bitter laugh covers both cases.