Agile is just a collection of stuff that people put together in order to ensure useful productivity from arbitrary teams. Often it's misapplied and misused, usually in order to micromanage.

The roots of agile come from the bad old days when the typical software project was a consulting gig with an elaborate negotiated spec and schedule and a huge disconnect between the buyers and the developers, let alone the users. And when the "software crisis" was in full swing, and many software projects failed to deliver anything of use, at all. Back in the days when even using source control wasn't common, and when regular builds and smoke tests were even rarer.

Agile ensures a few things:

It ensures that you use an incremental development strategy: start with something simple that works, then iteratively add to it over the course of short periods of work to move it closer to the desired state of functionality and capability. Because you routinely have workable builds this means you will always have something to show for your work at the end, because you have a pattern of having something working all the time.

It pushes the team toward continuous integration and regular builds with testing. Which avoids building up invisible technical debt due to undone integration work as the project progresses. Agile avoids the "big bang integration" problem.

It pushes the team toward visibility and interaction, so they get to know what everyone else is working on and it forces collaboration related to integration ASAP, all of which helps increase team cohesion and leads to higher code quality. People get to see the products of other's work routinely, making it easier to see what they're good at (and not) and aiding team mates in learning from one another.

It avoids unnecessary over-complications and the tendency to procrastinate, such as the notorious "second system effect". It ensures that people stay concentrated on real milestones and real work not pie in the sky perfect systems with schedule estimates off by orders of magnitude or not even feasibly possible.

It gives the "stakeholders" more visibility into the work. The product itself becomes the ground truth for the product, rather than a spec or a memo or a contract. If those folks have concerns they can be addressed and taken care of before it is extremely costly to fix. And if they want to make changes to the design relative to their initial thoughts, that too can be done fairly easily, resulting in an end product that is more suitable than would be the case otherwise.

And it ensures that sprint by sprint, work gets done, the product moves forward. With good teams this isn't a problem, but in the "enterprise trenches" with demotivated teams of average or below average coders this can be a real problem. It can be difficult to get anything done, let alone anything more than just spinning their wheels.

All of these things are for the most part good things, and they are the reason why the concept of agile has become so pervasive. The problem is that today a lot of the agile basics just go without saying (continuous integration, routine builds and testing, iterative development, short sprints for work, and so on) while some of the other aspects end up being applied in a cargo cult manner with no comprehension for why they were used as well as when they are warranted and when not.

Even if agile practices were being used correctly most of the time, which they aren't, it still would not be a good one size fits all practice for all circumstances. Moreover, the modern perversions of agile have done a lot of damage. Removing opportunities for use of initiative, creativity, and expertise by many coders, taking responsibility for even the tiniest decision out of their hands and transforming them into children. In some ways agile is like a remedial course in software engineering, but a lot of high caliber developers are finding themselves stuck with it even though it is restrictive and harmful, because management is thoughtless.