If Agile truly rejects even the possibility of an estimation (something I'm sure many proponents will disagree with), that would be a problem with Agile and not a problem with the idea of estimation. Companies will de facto pivot away to methods that will give an estimation, even if they're 'bad Agile' and even if software engineers are unhappy about it.
Because there are more useful things to optimize for than efficiency of software delivery or what software engineers like. People really need to know when the works on their street will be done, companies and countries need to plan ahead, and so on.
Not sure where the idea of "only look one sprint into the future thing" came from.
"The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago."
I agree with you - i dont think its worth trying to set a date a year out in stone. but you have to do exactly what you say. keep the trajectory in your mind and update it with new information. and and some point turn down the rate of change so you can get some cook time.
maybe I reacted too strongly - but I've certainly been in shops where I try to talk about overall project arc and am firmly told to keep my gaze fixed at exactly two weeks.
The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago.
The best you could probably hope for is Kanban or the never-ending backlog but some people struggle when there is no finish line, just an endless sea of work!