There is a misconception here: Agile does not encourage the project's requirements to change. It instead allows for change without wasting work, or sacrificing important areas of development.
There are four fundamental constraints to any engineering project; scope, cost, time and quality. Waterfall assumes that these will be static. That is an incorrect assumption; one or more of these ALWAYS change. Scope creep, slashed budgets, and other "unknown unknowns" ALWAYS interfere with a project, changing the constraints. Waterfall does not anticipate this, so when it happens, the project changes in undesirable ways; important features that haven't yet been added go away, or are quickly done, or the release has to be pushed back, or cost balloons as the PM throws money at new developers to come in and help get it all done right.
Agile, by contrast, allows constraints to change, and actually expects it. It does this by doing work in small, useable chunks, according to the priorities of the owner, and thus the chunks are ideally immediately useful to the project owner. Thus reduces exposure to the unknown by not making big plans out in a timeframe where the unknowns are large. If the timeline changes, teams can be added, or less important features "de-scoped", and the system the team has already built is unaffected.
It also provides for better estimates of the time and cost required to produce the given scope at the required quality. People are notoriously bad at estimating big jobs; it takes a LOT of experience, and a LOT more upfront calculation, to do it properly. By contrast, people are generally good judges of what they can get done in a day, or a week or two. That quickly produces a steady-state where you can extrapolate the time and cost of the work left to be done based on your historic pace, with a fair amount of accuracy.
As for defining endpoints, you're right; an Agile project CAN go on forever. However, so can the traditional SLDC; the client often comes back with more money and a wishlist of upgrades. The difference is that there isn't a clear line between "analysis", "design", "development" and "maintenance" when looking at the project as a whole; it all happens brick-by-brick, sprint by sprint. If at any point the owner wants to call the project "done", they can, and they will have the sum total of "bricks" they've paid for in a solid "wall"; it may not be as high or extend as far as they originally planned, but it's firmly in place, does the job, and can be added to at a later date with a minimum of tearing down.