Yeah it's a head scratcher for me too.
So many devs only want to work on a Mac yet they build software that runs on NOT Mac. Then they have to jump through hoops like architecture mismatch and docker having to run a Linux vm anyway.
Apple tries something weird every now and then and then a year later we get something different. Yes, Tahoe was a giant miss, but I'd wager macOS is not what really attracts devs to Apple anyway - it's the hardware that makes Macs such an appealing dev machine. Large glass trackpads with incredible touch controls, aluminum bodies, long lasting batteries, cool and quiet, great screens, years of support - the list goes on.
Snapdragon is only just now finally taking off in the Windows/Linux space, so the landscape could finally change here soon, but for now anyone who's gone ARM is not looking to ever go back to x64 hardware - at least for development (gaming is another convo).
Probably so, but I've seen more than a few Macbook Pro keyboards dome up due to heat so bad that you couldn't close the lid.
I recall Arch, Ubuntu, Debian and Fedora being used. Relatively small shop though, like 40 devs.
Ironically we were contracting with ASML at the time and ended up having to work on Windows machines using Remote Desktop 99% of the time.
RHEL is very popular on servers but not on desktops. Which is in part due to Red Hat themselves, they don't really do much to promote it for this usecase. Personally (as an admin) I don't mind because it's such a closed ecosystem anyway. They're always rent seeking which Canonical does a lot less. Canonical is always trying to sell us landscape though, but we never went for it because it doesn't solve any of the issues we have with the existing tooling.
Personally I wouldn't touch redhat with a 10 foot pole after what they pulled with centos, however if my work did want to I'd make an effort on their behalf. They don't seem to though.
As one example, on Linux most developer tools don't obey the system proxy configuration, each tool has its own archaic configuration for that. So we end up with a lengthy list of how to configure each tool for our MITM proxy. Sure, MITM proxies aren't ideal anyway but we're unfortunately stuck with this.
Many security tools have a Linux version but omit the GUI component where users can do stuff like request exceptions. Another big thing for developers because they often need that.
WiFi certificate auto provisioning is missing from the MDM tool we use. So it has to be all scripted. On windows and Mac we just click a box to turn it on. And this works differently on different distros.
So yeah as someone who builds Linux management I can imagine some companies don't bother.