If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)
HTML5 can't access TPM directly, but in ChromeOS, you can create or import a client certificate as a 'hardware-backed' certificate, which is then wrapped by the device's TPM.
At this point (if properly configured) an attacker can't exfiltrate client certificates from the device even with root-level access to the machine. Plus, in theory, extracting key material from the TPM should be made difficult by its manufacturer by means of various physical protections.
Obviously this is a very niche edge-case, but it is possible :)
Client certificates are generated by the user's machine and signed using your server's private key. The user's client presents them to your server to prove that the client is who they said they were when you signed their certificate. These certificates don't cost anything, besides some CPU cycles on both sides of the process.
The kind of server SSL certificates that cost money are generated by you and signed by a CA that most users' browsers will trust. Your server presents them to the client to state to the client that the server belongs to the domain it says it belongs to.
Most CAs will charge you money for the service of signing those certificates, but that process has nothing to do with the lack of adoption of client SSL certificates.
The parent article does a good job describing why client certificates aren't used more often: the UX doesn't make sense to users and there's not a user-friendly way to protect them with a second factor (the way you can encrypt your SSH keys using a passphrase or authentication device).
This is incidentally part of why the Chromebook design makes it hard to persistently change the machine; a reboot starts from a clean signed image and then mounts a home directory. It's still possible to stick a persistent exploit somewhere in the home directory, but it's not as simple as just dropping a file in /etc/init.