I often see Agile methodologies applied to the letter, some project managers use dogmas and do not question them. Can we say that Agile is first of all flexibility of application and freedom of interpretation? Remaining tied to the achievement of the objectives and not to the respect of rules of conduct or method.
This may seem pedantic, but you cannot apply Agile to the letter, it is just a series of values and principles. There are probably two aspects of what you are referring to. First, there are frameworks and methodologies in the agile umbrella and there are some very strong arguments for following those to the letter (to start). Second, there is an obsession in many industries with best practices and the idea that saying what you will do and then following that no matter what is somehow a good thing (spoilers: it isn't).
Frameworks in Agile
Scrum, XP, Kanban, etc are all pre-packaged approaches to getting certain results. You don't have to use them, but they are a shortcut off of someone else's success (or really, thousands of someone elses). The catch is, you void the warranty if you don't practice it as intended. Think of it this way: I need a new shelf. I could build a shelf in my garage, but that would require that I buy a bunch of tools, learn carpentry, practice and fail many times. Instead, I'm going to IKEA and buying a shelf. Now, I get the shelf home and I want to put it together. Should I follow the instructions or just start putting screws in holes until I run out of both? Well, it's my shelf, so I don't have to follow the instructions, but if I put it together a different way and throw the stabilizing brace in the trash because it uses a flat-head screw and I only have a philips driver, can I really complain when the shelf breaks?
I hope every team that uses scrum or XP eventually grows past it, keeping the parts that work and retooling others to fit their unique context. But you do that after you've used the out-of-the-box option and really learned why it works like it does. Then you customize.
To borrow some phrasing from the cynefin model, best practices only work with clear, simple problem. Complicated problems have a whole bunch of "good" practices with each one being slightly better depending on your circumstances. If you get into complex problems, there are only emergent practices. Knowledge work falls almost entirely in complicated and complex spaces, meaning best practices aren't really applicable. That means no practice should be taken as obviously the right thing to do. Everything is up for review. I have no idea how organizations have become obsessed with best practices, but it's really problematic.
Now, to tie those together: If I'm using Kanban, I should be using WIP limits. Otherwise, I'm not using Kanban. A corvette with a motorcycle engine in it isn't a corvette. Does that negate my statement about best practices? No. the practice of WIP limits should be up for review. But if you've never used this before, you don't have the knowledge to effectively evaluate its effectiveness in your context. If you try using a little piece of it, it's hard to tell if it didn't work because it's a bad fit or because you didn't use the supporting practices alongside. So, you practice one of these frameworks in its entirety to learn how and why they work, then start challenging them.
Daniel's answer does an excellent job of addressing Agile as a set of values and principles and the strict application of Agile methodologies and frameworks. However, I'd expand on the other question - can we say that Agile is the flexibility of application and freedom of interpretation?
The core of Agile is adaptability and responsiveness to change. I don't think there's much freedom in the interpretation of the values and principles. Still, there are some. The Manifesto for Agile Software Development was written about 20 years ago and built on work that is easily 25-30 years old (the work on various methods predates the Manifesto by several years, if not more).
The heart of adaptability and responsiveness (agility) relates to the product and services being offered. However, being agile requires some level of flexibility in the process. This is reflected in the Manifesto itself - "We are uncovering better ways of developing software by doing it and helping others do it." The practices of retrospective and process improvement are the only practices called out in any of the values and principles of Agile Software Development.
If you look at a framework like Scrum, however, there can be some rigidity in the rules that can enable agility. I believe that it is difficult to argue that Scrum done right does not promote agility. Note that this does not mean that you must follow Scrum to be agile, but rather that practicing Scrum in the context of the Agile Software Development values and principles can promote agility. However, there are specific immutable rules of Scrum that constrain the team. The existence of these rules does not make Scrum not agile.
The most important aspect of Agile is adaptability to the context in which the team works - the requirements, the technology, the stakeholders. Since the essential principle is customer satisfaction through the delivery of software, you can have more rigid frameworks that still enable product or service adaptability. However, too much rigidity could make it more challenging to adapt. It's a balancing act.