The answer to your question depends on the reader. There is no such thing as "maintainable code". Maintainability comes from the interaction between the code and the maintainance programmer.

That said, there is a fundamental tradeoff that I mentioned in Re (tilly) 2: To sub or not to sub, that is the question?:

Suppose that working with heavily factored and organized code is 5 times harder per page of code. Suppose that it does the work of 20 pages of unfactored and unorganized code. If you assume that the issue of tracking down the same bugs in unfactored code is similar to the issue of changes made for one reason affecting things all over the place, then that is a gain in productivity of a factor of 4. However whenever picking up that code I can guarantee you that you will feel that factor of 5 issue.

That tradeoff between density and readability seems fundamental to me. It isn't fixed in stone though, good programmers look for ways to improve density while minimizing the impact on readability. (Bad programmers keep density low. Really bad programmers try to increase density but don't pay attention to readability.) The point at which you should stop trading off density and readability because of the maintainability impact depends on your audience.

As a general rule of thumb, the more experienced the programmer that you're writing for, the more that you can expect of them. Pile things on beginners too fast, and they hit mental overload then balk. The same holds true for experts as well, but the expert has more generous limits.

UPDATE: Fixed broken link. Thanks, hardburn.