I think you are missing the author's points in your rebuttal.
Testing server -- maybe it's not ALWAYS possible with expensive enterprise-y server software, but just about anyone can spin up a VM on their dev machine to simulate (with varying degrees of accuracy) a production environment.
Secret logins & back doors -- you mean you've never created a "god" or "super admin" account (or "secret URL") that could access all kinds of technical / debugging info that regular admins/users shouldn't see? Having such an account means your application has additional logic & code paths to support -- code that's probably not being adequately (if at all) tested and probably has bugs, some of which may be security-related.
Test data in production - yeah, I've worked on systems (such as health care IT systems), where project team puts test data in the system. It sucks for operational users. "What, you mean Dr. Smith doesn't have a 2pm appt w/ TEST, DUMMY today?" "The compliance dept just got a call about a six-figure insurance claim to Medicare for a pregnancy-related hospitalization for a DUMBASS, JOE -- anyone know about that?" Test data belongs in a test database.
Frameworks -- in my humble opinion (and I'm not exactly alone) there are very few situations where run-time performance is actually "absolutely critical". More often (in my experience) time-to-develop "performance" is a bigger factor, and rolling-your-own (to get alleged better run-time performance) will cost you development time, bug-fix time, QA & testing-time -- which, for the vast majority of applications, will cost more than simply buying faster hardware (the happy medium way is to optimize just the critical slow parts in your application that the framework handles sub-optimally).
Choice of languages -- again, I think you missed the point. Any language is fine. His point is to keep your project consistent. If you've developed a hair-brained solution that involves Perl, cgi-bin, bash, PHP, and chunks of C -- it probably works great and flawlessly, like you said. Until that programmer (1) retires or (2) gets hit by a bus. Then the junior programming intern they hire to take his place is screwed. And that's the author's point -- write maintainable code. A mismash of languages & bindings "because they are cool" may function, but it's not maintainable. If your star programmer has this Perl/bash/PHP/C contraption and it's well-documented and logical, then maybe that junior intern will take it over and, with a bit of a learning curve, master it. But if your programmer used 4 different languages because "it's cool to make it complicated" -- well, good luck.