IAM is Identity and Access Management. The acronym was popularized (I think) by the AWS IAM service, although the topic of identity and access predate AWS cloud. When someone talks about IAM, broadly speaking, they are talking about who/what has authority to perform actions across the cloud infrastructure of an organization.
The concept of 'least-privilege permissions', in general, is the concept of giving the least amount of privileges and permissions possible to a user while still allowing a user to perform their tasks. (In this context, as user can be a machine-user or human-user.)
In the specific context of cloud services and IAM, this generally refers to restricting permissions related to cloud infrastructure maintenance.
Let's say you have a machine that deploys your source code to production. That's a pretty serious responsibility, since it controls what goes on your production servers. You might be inclined to give such a device "admin access" to your infrastructure, since it needs at least one major privilege: that of controlling what is deployed to prod. Now, if a hacker gains access to that machine, that's bad. The hacker can theoretically now control deployments to prod. But, if that machine also had admin access, they could, for example, remove all users except themselves from your organization. Now, once you've detected the malicious behavior, you've potentially lost the ability to fix it. By giving that machine generic, high-level access, you have increased your risk profile. Alternatively, if you gave that machine selective, high-level access, i.e., only giving that machine access to deploy, you theoretically could've prevented the worse scenario. This is the power of least-privilege permissions. It is an effective risk mitigation strategy.
While it is theoretically ideal to give all users, both machine-users and human-users alike, least-privilege permissions, it might also incur some usability penalities. Depending on how your organization manages 'least-privilege IAM' itself, it could hamper the development of your cloud systems. Why? Because a developer, perhaps, ought to have more permissions than what is least possible in order to do their work well. If the process involved in requesting privilege escalation within your organization is too onerous, an individual or team might just try to work around it. This then becomes a soft blocker risk.