Besides that, there isn't actually obvious different between firefox/chrome/edge on macos/windows.
The most problematic one is actually safari(which is on mac only). If you dev on chrome and use on firefox or vise versus. You usually get a "mostly work with minor visual different". But safari… will give you a fail and are't even usable. It is outright the modern age ie.
Doesn't sound sexy, no. Compensate them royaly. And make clear that they are superstars just by having this work environment. Then keep listening to what annoys them with whatever you are building, and let them fix it.
That, however, is bound to happen even if you have Windows workstations. It happened at a job where I was, in fact, running Windows, because the designer ran macOS and was oblivious to this issue. (Of course, I would fix it when spotted. But it still managed to make it out to prod at times.)
Or, leave the default settings in place, but plug in a mouse with a physical scroll wheel.
So it's not even that they're only using one platform, but they're only testing the platform with default settings with the default hardware. And we're not even talking about an obscure setting buried three levels deep, it's right there in the general pane!
sudo defaults write -g AppleShowScrollBars -string Always
But I also place the blame on design teams. Most design teams I've worked with also doesn't account for this in anything they create. They usually only design for: 1: the latest macbook pro; and 2: the latest iPhone.
I'll give you a point on VMs but it's cumbersome. There's a big difference between rolling to another machine or asking someone in the department who uses that machine every day and waiting for a VM to finish booting or using a service like Browserstack (and both cost $$ anyway).
Screen readers are not consistent across platforms, and things that work on Windows sometimes don't work on other platforms, and vice versa.
If that was not enough, I believe the CI runner is written in the Go programming language, which has a surprisingly decent abstraction of OS functionality in it's standard library. Imperfect as it may be, I suspect that helps reduce the amount of effort needed to ensure individual platforms work properly.
Maybe with a Windows VM.
The prohibition on developer laptops is not just a trivial or nitpicky detail; while the security of a VM obviously still matters, as you can't simply assume that malicious software in the VM can't escape, I would assume that the policy effectively means it would also be prohibited to setup a Linux dom0 and just run Windows under that and use it as your developer workspace. The benefit of only using Windows for testing is that you presumably won't be reading emails, talking on team chat, taking video calls, opening documents, etc. inside of Windows, only doing the thing you actually need (testing.) From a security standpoint, this can be helpful. I think that Windows vs Linux security is a rabbit hole not worth debating; both are very flawed and have many challenges, nothing is a panacea. However, I would say that every OS you don't need to harden is a huge operational advantage no matter how you slice it. You effectively cut off an entire slice of the malware market, and easily the largest slice in case of Windows.