The vibe I generally get from Graphene users is that they feel that they are taking control over their device by installing Graphene onto it (which is almost always a manual process, at least for now). I probably exaggerated when I said the vast majority of users care deeply about this, but I think it's still a major selling point of Graphene for a lot of people.
And yes, I do agree that sandboxing actually provides more control to the user, not less! I'd just hate to see Graphene become more like iOS over time and start intentionally omitting features that would otherwise empower the user, for security's sake. If "security" and "giving users a say in how their phone works" really are diametrically opposed, and user freedom isn't a concern, then it would probably make sense to start gutting out stuff like developer mode, adb, and sideloading for the user's own safety. But the project's track record has been pretty good so far from what I can tell, and I don't think this will happen.
In very rare cases, someone complains about the removal of pattern lock, but it's a terrible feature and shouldn't be included in modern Android. It's a much worse variant of a PIN which gives people a false sense of security and encourages choosing an insecure lock method. We also didn't want to support it for our duress PIN/password feature or our upcoming random PIN/password generation feature. It's not really suited to either of those things. Pattern lock is genuinely an awful feature and shouldn't be included in modern Android, but they don't want to upset people by removing it. Extremely few people care that we remove it, and we've helped them by getting them to use a PIN instead especially if they use a proper random PIN.
> developer mode, adb, and sideloading
These things can be disabled with a device management app already, if what you mean by sideloading is installing apps via an APK or arbitrary app store. Sideloading an OS update to recovery has all of the usual signature verification and downgrade protection.