I think it's hard to achieve all three. Two I think can be feasible. For example, I think it's possible to achieve efficiency and readability in some cases, but maintainability might be hard with micro-tuned code. The most efficient code on the planet will generally lack both maintainability and readability as is probably obvious to most, unless you're the kind that can understand the hand SoA-vectorized, multithreaded SIMD code that Intel writes with inlined assembly, or the most cutting-edge algorithms used in the industry with 40-page mathematical papers published only 2 months ago and 12 libraries worth of code for one incredibly complex data structure.
One thing I'd suggest that might be contrary to popular opinion is that the smartest algorithmic code is often more difficult to maintain than the most micro-tuned straightforward algorithm. This idea that scalability improvements yield more bang for the buck over micro-tuned code (ex: cache-friendly access patterns, multithreading, SIMD, etc.) is something I'd challenge, at least having worked in an industry filled with extremely complex data structures and algorithms (the visual FX industry), especially in areas like mesh processing, because the bang might be big but the buck is extremely expensive when you introduce new algorithms and data structures no one has ever heard of before since they're brand new. Further, I've managed to beat such algorithms and data structures with more straightforward code relying on general computer science and computer architecture knowledge, not cutting-edge industrial algorithms published by mathematical wizards, that "theoretically" didn't scale quite as well (ex: linearithmic vs. linear) but were micro-tuned, and my version required only about 1/100th of the code the scalable solution required while being faster for larger inputs (relatively faster the larger the inputs became, making my version even more scalable in practice even though it was less scalable theoretically).
So this idea that algorithmic optimizations always trump, say, optimizations related to memory-access patterns is always something I didn't quite agree with. Of course if you're using a bubble sort, no amount of micro-optimization can help you there... but within reason, I don't think it's always so clear-cut. And arguably algorithmic optimizations are more difficult to maintain than micro-optimizations. I'd find it much easier to maintain, say, Intel's Embree which takes a classic and straightforward BVH algorithm and just micro-tunes the crap out of it than Dreamwork's OpenVDB code for cutting-edge ways of algorithmically accelerating fluid simulation. So in my industry at least, I'd like to see more people familiar with computer architecture micro-optimizing more, as Intel has when they stepped into the scene, as opposed to coming up with thousands and thousands of new algorithms and data structures. With effective micro-optimizations, people could potentially find fewer and fewer reasons to invent new algorithms.
I worked in a legacy codebase before where almost every single user operation had its own unique data structure and algorithm behind it (adding up to hundreds of exotic data structures). And most of them had very skewed performance characteristics, being very narrowly applicable. It would have been so much easier if the system could revolve around a couple dozen more widely-applicable data structures, and I think that could have been the case if they were micro-optimized much better. I mention this case because micro-optimization can potentially improve maintainability tremendously in such a case if it means the difference between hundreds of micro-pessimized data structures that can't even be used safely for strict read-only purposes which involve cache misses left and right vs. just dozens of micro-optimized data structures that perform so much more efficiently all around.
Meanwhile some of the most maintainable code I've ever encountered was reasonably efficient but extremely hard to read, since they were written in functional languages. In general readability and uber maintainability are conflicting ideas in my opinion.
It is really hard to make code readable, and maintainable, and efficient all at once. Typically you have to compromise a bit in one of those three, if not two, like compromising readability for maintainability, or compromising maintainability for efficiency. It's usually maintainability that suffers when you seek a lot of the other two.
Readability vs. Maintainability
Now as said, I believe readability and maintainability are not harmonious concepts. After all, the most readable code for most of us mortals maps very intuitively to human thought patterns, and human thoughts patterns are inherently error-prone: "If this happens, do this. If that happens, do that. Otherwise do this. Oops, I forgot something! If these systems interact with each other, this should happen so that this system can do this... oh wait, what about that system when this event is triggered?" I forgot the exact quote but someone once said that if Rome was built like software, it would only take a bird landing on a wall to bring it toppling down. Such is the case with most software. It's more fragile than we often care to think. A few lines of seemingly innocuous code here and there could bring it to a halt to the point of making us reconsider the entire design, and high-level languages which aim to be as readable as possible are no exceptions to such human design errors.
Pure functional languages are about as close to invulnerable to this as one can feasibly get (not even close to invulnerable, but relatively much closer than most). And that's partially because they don't map intuitively to human thought. They're not readable. They force thinking patterns upon us which make us have to solve problems with as few special cases as possible using the minimum amount of knowledge possible and without causing any side effects. They're extremely orthogonal, they allow the code to often be changed and changed without surprises so epic that we have to rethink the design on a drawing board, even to the point of changing our minds about the overall design, without rewriting everything. It doesn't seem to get easier to maintain than that... but the code is still very hard to read, and almost necessarily so to be so maintainable (so easy to change without problems).