I think part of the problem is that, with 40 years now of software development history and tools having been built up, the learning overhead is massive. These smaller culty things promise huge results without the enormous time involvement of learning the old ways of doing things, so youngsters jump on them, and praise them to the skies when they mostly work.

But, as we saw with MongoDB, it can take quite awhile for the severe problems with a new architecture to become apparent even to the relatively inexperienced. With the old tools, you can find out about the really critical problems if you're willing to spend the research time upfront. There will be lots of small niggles that existing teams will just have learned to deal with, and don't really consider them awful flaws, so simple research won't tell you the whole story, but should prevent the worst disasters.

When considering new infrastructure software of that sort, I'd also look hard at who's behind it. Not the company (say, Google), but the actual engineers doing the work. Somone like, say, Tridge, the lead on Samba and designer of rsync, would get instant respect from me; if he had a new tool that sounded like something I could use, I'd adopt it instantly.

This is more of a positive-only association, though, in that even horrible projects like PHP probably taught their developers a great deal about What Not To Do. Being a dev on a bad project wouldn't count against, most of the time. But if they've been involved in writing something really great, that will move their new projects way up my priority list.