I don't understand your last point:

"if you have to give a fixed date for delivery - it's very, very difficult to be agile"

An agile project delivers continuously. So you can deliver every time, especially at a fixed date. The fact is, that if you have to be feature complete at a fixed date, you can't be agile. Hence, you can't be feature complete at a fixed date in an agile project.

"fixed date" in this case means "We have the following list of features we want in the product, to be launched as our big update. How many months will it take? (and we'll hold you to that exact date)"

The further ahead you must forecast, the less accurate your estimate will be. In many organizations, the hapless architect is asked to give a solid date for a laundry list of features, many of which he can't research very well up front. Many technologies exist to solve a number of the problems, but the experienced architect KNOWS that each and every one of those technologies will fail to work, be poorly documented, be poorly supported, contain subtle bugs that affect nobody else but him, be incompatible with existing infrastructure, etc. There will be a great number of dead ends, which can only be discovered once the team has spent a good amount of time learning the technologies via documentation, web searches, object code disassembly, threatening vendors' families and pets, and so on.

And fixing these emerging problems will involve other technologies, each with their own problems, resulting in a factorial solution set.

This is why the traditional method of estimation has been to estimate how long you expect it to take with a lot of things going wrong, and then triple it (you triple it so that you can be "talked down" to double, even though that increases the risk of going over).

In short, long term project completion forecasts are a fairy tale, and so anyone who expects you to adhere to them makes agility near impossible.