Dan McKinley wrote a great blog post about choosing boring technology. It's worth reading, but the tl;dr is that by adopting new and exciting technology you introduce additional risk and instability, which limits your ability to innovate on your product. I agree with pretty much everything he said.
There's another dimension to the boredom question though. I think it's both a cause and effect of what Dan's talking about. I call it Ian's Rule Of Bored Programmers:
A smart programmer tasked with solving a simple problem will make the problem more complicated until it becomes interesting.I've observed this time and time again both in companies and in the open source world. To me the classic open source example is the GNU C Library. The team developing the glibc library, led for many years by Ulrich Drepper are intelligent and experienced, but they working on a library that for the most part is wrappers around syscalls, plus printf and malloc implementations. Almost every user of their library is using the Linux kernel. Instead of a simple, stable library we've ended up with a complex, always changing source of innovation and bugs.
At companies that only hire experienced programmers I've watched experienced developers faced with a simple but important problem add complexity to the solution to keep their attention. In some cases it takes the form of adopting or developing new languages, databases or other technology (like Dan writes about). In other cases developers chose to solve an abstract problem class rather than the specific concrete problem at hand, which ironically often ends being more brittle and inflexible than a solution specific to the problem would have been.
There doesn't seem to be an obvious solution to this. Sometime simple problems are important enough that we want someone with experience to tackle it. For myself I just try to check in with myself to make sure I'm not adding complexity where it doesn't belong.