The TLS fingerprint uri it's blocking doesn't collect any information from the browser, sites can still use it as a fingerprint on noscript-disabled browsers.
Similar: https://ja3er.com/ which is formed by taking a bunch of (stable) attributes from your TLS handshake, appending them into a string, and hashing it.
They've also done the correlation with User Agent and it's surprisingly accurate.
They say they're doing the clienthello message. That would change depending on if its your first visit to that domain or second because your second would use session resumption.
This seems... kind of pointless? You'd expect the fingerprint to be fully determined by the OS/browser combination, since TLS is implemented entirely in software. But you can already get both pieces of information through the user-agent, so what's the point?
For those exposing a lot of fingerprintable data it doesn't help much but that's not really a problem since there is already plenty of fingerprintable data.
For those trying to hide/fake fingerprintable data the mismatch between spoofed user agent and detected browser/OS combo creates a strong fingerprint in itself.
This is the general premise of fingerprinting: if you throw enough data points at it trying to escape fingerprinting itself creates a unique fingerprint.
Update: Works - Brave users - you need to disable Shields for it to show your fingerprint.