Isn't its methodologies - it's the fundamental premise that it's a solution for everyone and every thing.
If you're building custom solutions for anyone (consumer, SMB, Enterprise) - Agile is likely your friend. Go with Agile.
If you're building a consumer facing web application - Agile is possibly your friend, it depends on how clear a vision you have. If you're not sure - go with Agile.
If you're building a PRODUCT (something you expect to use unchanged - excepting, of course, new additions and features) for the Enterprise - Agile is NOT your friend - but it is most certainly the friend of the integration team who will be deploying your PRODUCT into that enterprise.
Agile is hugely beneficial in the right scenarios - usually a scenario where the people who want something don't know what it is they actually want - they just know they need something fixed.
Agile is hugely detrimental in the wrong scenarios - for example when you have a company that hires 'Agile Product Managers' who are NOT domain experts; ergo, they have no idea what is or is not good for the target market verticals.
The other problem with Agile is that they created (somewhat accidentally) a strawman argument to establish themselves - that if it's not agile it's some kind of horrifying version of 'waterfall.' In other words, a black and white situation that's simply bullshit.
I've run teams where Agile was the only reasonable approach - and it worked well for us. I've run teams where Agile would have been a disaster for us and a waterfall/spiral type of approach worked well for us.
Tools in a toolbox people - just like operating systems, languages, patterns, testing methodologies - et cetera. Right tool, in the right place, at the right time.
Know them all (or as many as you can) - know their strengths and (sometimes more importantly) their weaknesses.
The really interesting time is when you build a startup and as the company matures, so does everything inside of it (technology, operations, organizations, processes, et cetera.) You may spend 90 days head down and very NOT agile, and then at seed round embrace Agile because it's right for you. You may be agile for a year or two until you close an enterprise deal - and then perhaps you re-evaluate using Agile - or modify it.
The point is (that I am very poorly making) - You need to know when Agile, and/or some particular aspect of Agile, is or is not appropriate for you and either embrace it or distance it. Don't fall for marketing hype, or the legions of people who cover their incompetencies (primarily in the world of Product Management) by hiding behind it.