A fifty-year-old rule
The principle was written down in 1975, in a paper on protecting information in computer systems, as one of eight design principles: every program and every user should operate using the least set of privileges necessary to complete the job. Nothing in that sentence has aged. What has changed is the number of things that hold privileges, from a few operators to millions of accounts, keys and workloads, and the cost of a single over-privileged one being compromised.
The damage from any compromise is bounded by what the compromised identity could do. A phished employee with access only to their own email is an incident; a phished employee whose account also holds administrator rights on the domain is a disaster, and the difference is not the phishing but the privilege. The same logic governs software: a web application that connects to its database as the database's owner can be turned against every table by one injection flaw, and the same application connecting with a role that can read two tables and write one cannot. Least privilege does not prevent the initial compromise. It decides what the compromise is worth.
The reason it fails in practice is asymmetry. Granting access is fast, visible and thanked; removing it is slow, invisible and resented. So access ratchets upward, project by project, until a routine account can do things nobody intended. The design that reverses the asymmetry is expiry: grant elevated access for a bounded time with a stated reason, let it lapse automatically, and require a fresh request to extend it. That makes the default state minimal and the exception the thing that requires effort, which is the only arrangement under which the principle survives contact with a busy organisation.