Re: SUDO and +s is a design weakness
If you want, you can make it very easy for nonroot users to do lots of things, including adding restrictions to exactly which users can do those things. The utility of sudo is that, should you want to change what they can do, it's a lot easier. Say you do want to allow some users to modify /usr/local, but not to have other root permissions. We're using this as an example, but in reality that would be a terrible thing to let them do as that would provide them a great deal of access to mess up everything.
If you do it the old way, by adding them to a group and assigning /usr/local to that group, it's easy. Anyone in the group gets the access you set. If you want to remove that permission, you kick the user out of the group. Easy. Unless you left the company and I'm running the system now, because I don't necessarily know all your groups and what you let them do. You've probably documented it somewhere, but that might be for some systems but not others, or somebody lost your documentation, etc. So now there are users whose access I can't cut off because I don't know it exists. I could do a global check of the filesystem to see if there are any unusual owners or groups, and after I find this first one I probably will, but it's not at all something a new admin would be expecting.
There's another classic way to expose functionality to users: a program running as root that receives user commands. The program itself has root capabilities, but the user doesn't. They issue the command they'd like, and that program determines if they have the rights to execute that command and does so. This works well too, and it lets you introduce even finer controls on what someone can do. So, for example, you can block them from installing a compromised copy of a utility over an old one, but continue to allow them to write new files in there. This is harder for the user, as they'll have to learn how your program works. It's also harder for you, because you'll have to write the program. It's a little easier for me, because your program will either have to have a server component which gets started on boot (thus I can easily see it) or at least it'd be in a directory on a path. Of course, if I don't have source code for this program, my life is really annoying.
Now, we have sudo. Sudo is limited, and it can have flaws. No question about that. But it allows you to relatively easily define who is allowed to do what. It can require their password, so even if someone gets access to an open terminal of theirs or one of their SSH private keys, they can't elevate easily. Your program could do that, but only by replicating sudo's functionality to a certain degree, and the owner and group solution doesn't give you that option at all. It's easier for the user because the commands are nearly always the same. It's much easier for me. If I want to know who has special access, specifically what, and what they do with it, I can find all of that in the sudo configuration files and logs. It's one place, and it's now common enough that it's a typical place to check when administrating a new system.