If you ask 10 people what agile "really" means you'll get 10 different answers, many quite incompatible with each other.
Beyond that, 10 people might find that the processes they've refined from Agile really do differ. That might be because of differing (and broken) application of Agile itself, which is a common claim. It might be, though, that continuous improvement of process has lead different teams in different directions that function well or well enough for those teams.
You could replace the entire thing with "shorter feedback loops" and it would be significantly more meaningful.
If you actually read it it really is just a bunch of words that doesn't specify much of anything at all. To me it reads as something incredibly vague and hand-wavy and how on earth modern Agile has been inferred out of the text of the agile manifesto is somewhat beyond me.
It's vague exactly because it's a manifesto, not a handbook on how to apply it.
I saw the transition of the industry from a complete waterfall process to the overhyping of agile, the pushback and now the land where agile as per the manifesto is more-or-less a given. The old ways were so much worse...
The bad sprouts from agile are the multitude of processes and bullshit methodologies that tried to ride the hype and create "The Agile Way". Scrum and others are a side-effect of this and I'm very glad to see Scrum being shunned for the past 4-6 years and instead engineers being attracted towards much more lightweight processes.
The problem with agile is that it only works when people had experiences, bad and good, and a team can tailor how their agile process should look like given their constraints. Throwing a bunch of juniors under an agile methodology and telling them what's right or not only creates friction and useless rituals, you need experienced people (PMs, EMs and at least one engineer) to cut the bullshit and stick to the points that matter: collaboration, communication, re-assessment of priorities, etc.