Respect feature service edit settings for privileged accounts

[Zagorki]

Currently, when a feature service is published that has editing privileges (any combination of create, modify, delete) turned off, Portal admins (or users with the right role) can still edit through applyedits in REST or natively in Pro. This is true for hosted data and referenced from an enterprise gdb. Specifically for branch versioned data, we need to publish as the schema owner, so it really limits our ability to control editing rights. A Portal admin may not be the data administrator. I would like to see feature services adhere to the editing privileges that are set for all users. I am comfortable with publishing the data twice for viewing and editing needs and using groups to secure access.

[DarylHochhalter]

I couldn't agree more! I don't understand why I would want any user account to override privileges set on the service. This was a way that we were able to fine tune and track who is editing and what they could do. I may not want anyone to change features in a service and only want attributes updated, but with this override other users can do whatever they want. It's not just admins either, I have a professional user who can also edit anything I publish, not the data owner or an admin, although has some elevated privileges. I really don't understand why anyone would want this? You are essentially giving access to the database to any portal user with elevated privileges.  I really don't even want my own account to override the service settings. 
I would appreciate it if someone explained the thinking on the other side of this?