Sounds like you’re railing more against the Enterprise appropriation of agile terms rather than the process itself. My experience is that most large companies “doing agile” either proceed with waterfall with agile terms, or let a project flop around chaotically and *label* it agile.
The valuable takeaways I see from this piece are your observation that story points delivered at the end of a sprint aren’t in of themselves useful enough for forecasting. Sure! But unlike your assertion that agile project results are “trash,” sprint delivery allows you to make sure you deliver high-quality working bits of functionality only — as evaluated by your developers and the client/stakeholder/user who the software is FOR.
If the development team is delivering software to their boss-stakeholder, then you’re doing it wrong. If you have to deliver 100% of a list of features by a certain deadline, your contract is doing it wrong. Yeah, Agile Consultants tell you you’re doing it wrong and stodgy enterprise shops can never seem to get it right, but that doesn’t mean there’s No True Scotsman. Re-engineering your processes using just the practices you need is the Right Way to attempt agile in rigid business environments. Take what works, discard what doesn’t.