While there are multiple approaches here, the best approach and the key to security on the desktop is to assume that any userland software running is already compromised. In other words, place your trust in the operating system, not the programs. If the operating system is compromised... it is time to replace the computer.
You mentioned sudo as a way to authenticate to install (not download) system packages. This is because the package manager is locked down and requires root (group or user) access. In other words, apt-get does not enforce security itself, it simply does things that require root access. On my system it is r-x for the root group, of which I am a user. So I can execute it, but it cannot do anything useful unless it runs as root because the things it attempts to do require root access.
In the same vein, a userland program should not care too much about security. Instead, it should rely on the credentials of the logged-in user to allow it to access system resources that are secured by the operating system. If the user needs elevated privileges, then run as root, use sudo, or right-click and "run as administrator" in Windows.
In theory, any application-level security can be broken in a matter of time by anyone with access to the system.
Even server software such as SQL Server follows this model by preferring to rely on system groups and privileges. If you try to use SQL Server authentication and turn off the group-based security it will warn you this is not secure -- because it is not.
Remember, the OS is in a special, privileged execution environment that gives it unfettered access to all system resources. Applications in modern operating systems do what the operating system allow them to do. Leverage that built-in security and do not reinvent the wheel.
To address your question more directly, it can be acceptable to authenticate in the program itself if you are installing plugins to the user's profile, localizing any damage to the user's account. However, that is rather pointless as you do not require any different privileges to finish the action. I would still recommend not authenticating, and relying on the built-in security to let the action succeed or fail (in this case, most likely succeed).
The only time it truly makes sense to enter a password without elevating privileges is for encrypting or decrypting data: but that should not be a user account password anyway.
