That statement is true in the context of cutting edge code and technologies, however, in the context of overall development, which is including legacy code, it is not true from my experience. As a consultant, I'm constantly switching between technologies as I move between different clients.
For example, my last position involved Spring 3.1 using Annotations and Web Services with CXF, but prior to that I recently had to do work with some very old legacy java code (15 year old+ codebase) that had recently upgraded to Java 6. Another client I worked for is still using EJB 2.0 and isn't changing anytime soon.
My point is clients have invested heavily into certain technologies and they aren't going to change overnight. Those technologies and codebases are generally stable, so the client doesn't want to jeopardize that investment by constantly changing their core technologies. Therefore, older skillsets will always be in some demand beyond the 18 months guideline.
Keep in mind one of the cardinal rules of business, things always change! Whether it's fast or slow, every industry always experiences change. One notable example in our industry was change that Y2K brought for COBOL developers. I would have never thought their pay rates would rise, but they did around Y2K and then adjusted themselves afterwards. I had a relative that was doing COBOL at that time and he said he knew it wouldn't last, but he was getting good pay at that time.
So my point is learning programming knowledge is not static. It's a dynamic thing that can change. I still get contacted for Visual Basic work, but I haven't done that work since 2001 when I switched over to Java development.
Again, the question is true, but not in the universal sense that you imply in your question. It is not a universal maxim for programming, like "Bug free code is more important than clean code" or "Keep things as simple as possible but not simpler." or "Don't re-invent the wheel" and such like.