Hello,
I feel like some of the principles are misinterpreted, at best.
For example, I always get a bad feeling when someone refers to agile methodology, there is no such thing: agility is an approach, not a methodology, and there are some frameworks that try to implement the principles, those can be call methodologies, and I am talking about SCRUM, XP, LESS...

Another thing I'm not comfortable with is the criteria of adoption: "when the requirements of the software are not complete or when we has less information and we can change the development when we want".
In 2018 it is no more a matter of when applying an agile approach to development, but which practices bring the best results for your team or your company.
There is no such thing as "complete requirements", or "stable requirements". Requirements are based on needs and context, which are recursively influenced, and even a small percentage of the total expected value WILL (yes, capital) change both the needs and the concept; so, let's move away from the illusion of stability, embrace change, and make it your priority.

Lastly, it looks from your post that an agile approach has a very determined set of advantages and disadvantages - and I will spare a severe comment about listing "active user close collaboration" as one of the latter - while there is no such thing as they both depend on the way you decide to implement the agile principles and which problems matter more.
I, for example, cannot think of any disadvantage in frequent delivery, or integrated testing.
What you should have mentioned, instead, is that adopting agile principles is hard, it requires constant change, it requires technical skills, it requires your company to change, not just your IT department, but your whole company, it requires maturity, and, most of all, it requires failure and embracing it as a mean to improve rather than playing the usual blame game.