I can't recommend becoming the owner of /usr/local; for most situations, it's probably less secure than using sudo.

Your question suggests two reasons you might want to chown /usr/local.

The first is to avoid having to use sudo to install software. This might read to some (such as the author of this answer) as saying you want to work efficiently, or save the keystrokes needed to type sudo and enter your password. But probably when you say "unnecessary," you are referring instead to the principle of least privilege:

By default, root owns the directory. This means that to install there, you need to use sudo. For a single-user or developer machine, this seems like unnecessary extra use of the command

I quite often hear/read folks opining/complaining along the lines of "I'm the only one who uses this system, so I shouldn't need to use sudo and enter a password." For readers who are of that view, and because it's relevant here, let's remind ourselves of a basic security reason for root to own things.

Most of the program files installed on an Ubuntu system have file mode 755, or in symbolic notation rwxr-xr-x, meaning that any user or program can execute them, but only the owner of the files, root, can modify them. (Technically this also requires that no one but root have the w permission on the directory that contains them, so other users can't delete or move them.)

This means that you, the humble user, may execute any program. If you try to use a program to do something you don't have permission to do, like perform a write operation on a file owned by root, it will error out. This makes a typo in some command, a buggy application, or malicious code, less likely to mess up your system - unless it's running as root, it won't have permission to do so. This is especially useful when running programs that interact with the internet.

If you chown /usr/local, any program running with your privileges could write files there, which might later get executed as root for some reason, such as by superseding another command of the same name. /usr/local/bin is in the default $PATH, and in sudo's secure_path, and it comes before other locations in both. So if I have two executables

/usr/local/bin/chown

/bin/chown

when I execute sudo chown ..., the chown in /usr/local/bin will be executed.

But you probably already knew all that, since your second reason is about security:

Additionally, if you have locally compiled software installed to /usr/local, the software currently needs root to modify themselves or install plugins. This seems unsafe - I want to only use sudo when I know EXACTLY what will happen.

_{Just in case it's necessary to mention this here, it's absolutely right (according to the FHS anyway) to install locally compiled software to /usr/local, but compiling itself should be done somewhere in your $HOME, without sudo, until the last step when you type sudo make install or equivalent.}

I think you're suggesting that by running a program installed in /usr/local as its unprivileged owner, you could use specific permission errors thrown when it tries to update itself to see that it's trying to modify some other filesystem location not owned by you in a way you don't want, so that you could stop it from doing so.

This might be helpful. The implication is that you trust the program to do anything it likes within /usr/local, but not elsewhere. If it requests elevated permissions, you could refuse to allow it to update, or uninstall it. That makes some sense to me. But I think trying to use /usr/local as a kind of sandbox in this way is probably not a good idea, or at least it's unlikely to be the most secure solution. It's not a properly isolated location (/opt is a little more isolated, since it's not in the default $PATH). The program might write or delete something in /usr/local to cause harm. Other (potentially poorly written) programs you run may write and execute code there that you aren't aware of.

If you're worried about allowing a program to update itself securely, you should probably look for alternatives (specific to the program perhaps, as with python for example, or you could look for a snap or similar implementation that suits your needs, or use containers or a VM to test potentially unsafe software) before exposing a system location (even a relatively user-y one) to be written to by programs run by a normal user. That seems to me as likely to have unpredictable effects as allowing programs temporarily elevated permissions with sudo.