But you can't do this "those 128 bits are used but are kept not known" thing with software. Sure, it is being tried again and again, and it fails every time.

You need separate hardware to safely prevent these 128bits from leaking.. but then why don't we ditch whole idea and implement true HW RNG instead?

I don't think you understood what he was saying, because if you think "you can't protect 128 bits in software" rebuts it, you also don't believe that any software cryptography works, in any setting; virtually all of it involves managing secret or unpredictable 128 bit values.

His point is that the mechanism used to generate random bytes by a modern CSPRNG is virtually identical to the mechanism that encrypts the application_data in a TLS session.

So you see absolutely no difference between leaking /dev/urandom PRNG seed from which all random numbers are generated for days or weeks, and leaking just one key for one TLS session?

Mechanism can be identical, but the stakes are definitely not.

Because we don't generate random numbers to look at them and marvel at their philosophical pureness, we use them. In software.

So those bits will be known to software, no matter where the generation happens.

Your argument would make a bit of sense if you were arguing for doing all cryptographic operations in hardware. Like on a smartcard. But that's not what we're talking about.