If you are going to say "the things this methodology directly says about development aren't related to it", then you can defend absolutely any methodology on such a basis. Your logic is completely contradictory; can we say traditional Waterfall has no faults because people did it wrong? No, it has faults. Unlike with Agile, it just wasn't possible to fix said faults (Agile was not a solution).
"If your product owner is accepting every single customer request and team cannot cope with it you need to adapt as team to see how to make that working, as simple as that" - that's exactly the problem. In commercial environments "adapt the team" is most frequently accomplished by just pushing devs harder, because other solutions cost more money and are more difficult to do; forcing devs to work harder and longer is easier in comparison. Ask yourself why so many software companies still have crunch periods: try telling any of them that they should 'adapt the team' and see if it leads to a different conclusion than pushing workers harder.
"It should be what works for your client, company and team" - OK, so why do you need Agile at all? What possible advantage comes from writing it? Those who 'follow it correctly' will do what you would do without the manifesto, and those who don't will make the project worse. There is zero benefit here. Your mistake is assuming that anything involving small projects equals Agile, which is not true. Frankly we don't even need the term 'modern Waterfall': splitting projects into small pieces is enough. A methodology shouldn't give priorities, especially bad ones.
"That is again what I see wrongly in rest of your proposal. It inherently forces that there is a manager telling team what to do, “allocating a percentage of worker time to documentation and maintenance”, which is exactly what software development industry is moving from." - let's assume this is true: what's your plan? Ask devs to do maintenance in their personal time? Make all maintenance part of billable projects, even those that have nothing to do with the customer at all? I wonder how you justify that to your clients, or is it just hidden from them?
"This has to come from development team, and they are exactly free to do it in Agile." - unless you're telling me that in your idea of Agile, your developers have no superiors in the company and are accountable to no one, then no. They are not 'free' to do it in Agile at all, that's dictated by commercial reality. They're free to do it if their manager allows them to, that has nothing to do with where the industry is moving.
Also, I can't believe I need to point this out, but the term "agile development team" is possibly the most subjective phrase on the planet. It has a different meaning in pretty much every single company that practices Agile.
