• Your operating system
• Your CPU architecture

Agree. No reason they should have this.

• Your JS interpreter's version and build ID

I can see a reasonable argument for this being allowed. Feature detection should make this unnecessary, but it doesn't seem to be fully supported yet.

• Plugins & Extensions

This is clearly a break of the browser sandbox and should require explicit permission at the very least (if not be blocked outright...I'm curious what the legitimate uses for these would be).

• Accelerometer and gyroscope & magnetic field sensor

Should probably be tied to location permission, for the sake of a simple UX.

• Proximity sensor

Definitely potential legitimate reasons for this, but it shouldn't be by default.

• Keyboard layout

As someone who uses a non-QWERTY (and non-QWERTY-based) layout, this is one I have quite a stake in. The bottom line is that even without directly being able to obtain this, a site can very easily indirectly obtain it anyway, thanks to the difference between event.code and event.key. And that difference is important, because there are some cases where it's better to use one or the other. A browser-based game, for example, probably wants to use event.code so the user can move around based on where WASD would be on a QWERTY keyboard, even though as a Dvorak user, for me that would be <AOE. But keyboard shortcuts like J and K for "next"/"previous" item should usually use event.key.

There could/should be a browser setting somewhere, or an extension, that can hide this from sites. But it is far too useful, relative to its fingerprinting value, to restrict for ordinary users.

how sensors are used to fingerprint you, I think it has to do with manufacturing imperfections that skew their readings in unique ways

It's also simple presence detection. "You have a proximity sensor" is a result not every browser will have, so it helps narrow down a specific browser.