Requiring a few hoops - and it sounds like e.g. requiring a developer edition sounds like such a hoop - to ensure a likely misconfiguration was actually intentional and the user is capable of dealing with the consequences is not a bad idea.
In particular, debugging when things go wrong can be an insurmountable task.
Better isolation of software components has been a trend for decades; to the point where I think we can safely say that the old unix and windows model of permissions was a fundamentally insufficient idea. Devs flock to using VMs and containers precisely because uncontrolled interaction between stuff even controlled by the same nominal "user" is a huge pain - and that's before malware and privacy concerns come in.
Were software more isolated by default, and interaction more controlled and/or explicit, then indeed I think the argument against this kind of controlling-the-"user" features would be stronger. But as is? The alternative is clearly much, much worse.
After all, certainly here and often in other cases too - it's not like it's actually impossible to circumvent these restrictions. It's simply technically inconvenient in a way that happens to also prevent many unintentional bugs and some malware vectors.
In an ideal world, a devs for a piece of software would be hard-pressed to even do this, let alone feel the need to do it. But that's just not the world we live in; we're not even really close yet - except on really locked down platforms that go much further than needed to prevent the risks, and into the territory of quite openly restricting the user, not the software.