Context is everything!
I completely agree.
I work on a number of web-based applications and for our applications we rarely see tables with more than 100K rows. On the other hand, we have more than 10,000 source files being maintained by a team of 5 developers. In this situation, developer time is way more expensive than disk space. In 99% of all queries or stored procedures, response time is never even close to being an issue.
Ok. As you said, context is everything, and the context of my article is dealing with much larger systems, so what you are getting at here is really not at odds with what I was saying. I also did state in the article to "be sensible, not wasteful" and it sounds like you are being sensible for your particular needs.
To invest time re-factoring the first solution to be more disk-efficient is a bad investment. To make design choices that trade off ease of developer (maintenance) understanding for disk efficiency (space or time) is a bad investment.
I specifically stated in the article to consider the recommendations for new projects, though there are certainly situations, even if not for you, when refactoring is a good investment.
Regarding design choice trade-offs, once again it all depends on the particular situation. For small-scale systems you are generally correct, but for larger systems (which are the main concern of this article) it is a good investment to err on the side of overall system efficiency. And for small to mid-size systems there is usually a decent compromise. I was discussing this very point with a developer the other day who designed a series of tables that have a variable-width text field to JOIN on. He was being told that he needs to convert that to TINYINT and was unsure of the benefit since the time it takes him to track down data feed problems would increase if he had to remember the 50 or so values rather than just immediately seeing the data he needs and understanding it without having to query an additional lookup table. Given that he, too, was working on a system that would never reach 100k rows in any table, I recommended using a CHAR(3) or CHAR(4) field, maybe even CHAR(5), to hold a code that represents the full text in some meaningful way. That is an efficient solution that not only lets him keep the ease-of-use factor, but is also more maintainable given that the spelling of the full text of those values could possibly change and if that ever happens then he would have to find and update every table that has that field.
Just FYI, I have submitted an update to this article that adds an extra paragraph in the Conclusion section to more explicitly clarify these two points given that a couple of other people had similar misinterpretations of what I was saying. Now I clearly state that I am not talking about refactoring unless the situation calls for it, and that smaller-scale systems might benefit from erring on the side of developer ease-of-use. I am not sure when that change will be made active, but hopefully soon.