I get your points. But we simply wouldn’t get along at all. Even though I’d be able to provide every tool you could possibly want in a secure, policy meeting way, and probably long before you actually ever needed it.

but I hate debugging build and runtime issues remotely. There’s always something that remote system is missing that I need

If the remote system is a dev system… it should never be missing anything. So if something’s missing… Then there’s already a disconnect. Also, if you’re debugging runtime issues, you’d want faster compile time anyway. So not sure why your “monolith” comment is even relevant. If it takes you 10 compiles to figure the problem out fully, and you end up compiling 5 minutes quicker on the remote system due to it not being a mobile chip in a shit laptop (that’s already setup to run dev anyway). Then you’re saving time to actually do coding. But to you that’s an “inconvenience” because you need root for some reason.

but my point here is that security should be everyone’s concern, not just a team who locks down your device so you can’t screw the things up.

No. At least not in the sense you present it. It’s not just locking down your device that you can’t screw it up. It’s so that you’re never a single point of failure. You’re not advocating for “Everyone looking out for the team”. You’re advocated that everyone should just cave and cater to your whim, rest of the team be damned. Where your whim is a direct data security risk. This is what the audit body will identify at audit time, and likely an ultimatum will occur for the company when it’s identified, fix the problem (lock down the machine to the policy standards or remove your access outright which would likely mean firing you since your job requires access) or certification will not be renewed. And if insurance has to kick in, and it’s found that you were “special” they’ll very easily deny the whole claim stating that the company was willfully negligent. You are not special enough. I’m not special enough, even as the C-suite officer in charge of it. The policies keep you safe just as much as it keeps the company safe. You follow it, the company posture overall is better. You follow it, and if something goes wrong you can point at policy and say “I followed the rules”. Root access to a company machine because you think you might one day need to install something on it is a cop out answer, tools that you use don’t change all that often that 2 day wait for the IT team to respond (your scenario) would only happen once in how many days of working for the company? It only takes one sudo command to install something compromised and bringing the device on campus or on the SDN (which you wouldn’t be able to access on your own install anyway… So not going to be able to do work regardless, or connect to dev machines at all)

Edit to add:

Users can’t even install an alternative browser, which is why our devs only support Chrome (our users are all corporate customers).

We’re the same! But… it’s Firefox… If you want to use alternate browsers while in our network, you’re using the VDI which spins up a disposable container of a number of different options. But none of them are persistent. In our case, catering to chrome means potentially using non-standard chrome specific functions which we specifically don’t do. Most of us are pretty anti-google overall in our company anyway. So

but it’s nearly impossible to tell the good from the bad when interviewing a company.

This is fair enough.