The Advent that became Tribulation

There is a nice initiative in the php community whose goal is to put together a set of best practices for php programmers and to having them explained every day of December from experienced developers: the PHP Advent.
However, this year I have been disappointed by the quality of the articles in the advent. First, there is no Add Comment form. What? What advent is this, 1995's one? Are the articles stored as static html files? I remember there were definitely comments in 2007.
After having asked the reason on Twitter, I got this response:

@giorgiosironi we've considered adding it, but like the idea of crosslinking with our authors' blogs when they create an entry. /cc @chwenz

The problem is that there is no duplicate post on the author's blog, at least for the majority of them. The only place where leaving a comment makes sense is on the original article, which admits no feedback.
Now we can start to list what I, and probably many other developers, would have commented on some of the articles.

December 8: Testing with PHPT and xUnit
The author suggests to abandon the standard testing framework for php, PHPUnit, to use PHPT, the testing harness for the php core itself.
PHPT has a very simple plain text interface where you specify text files containing the code to execute and its expected output. Not as variables - as text output, usually of var_dump(). This tool is used to testing php itself because using a real framework with more features, like PHPUnit, means that it will probably break while running the test suite if a regression is introduced in php.
Then what are the reasons to dismiss PHPUnit if you are not developing the php interpreter? The author say "with PHPT you can test for expected fatal errors!". Why I would want an expected fatal error in my application? With a nice blank page shown to the end user? I can't even think of renouncing to PHPUnit.

December 12: JSON Gotchas
Towards the end of the article, the author says something like: You know what is really cool? Passing an anonymous function in a Json string.

var jsonString = "({name: 'value', toString: function() { return this.name; }})";

What's the problem? That this is not Json, it's plain javascript syntax... Json.org says a value is string|number|object|array|true|false|null and an object is something which is enclosed in {}. Do you see anonymous functions in this specification?
This Json string would probably work if passed to eval(), but not to secure Json parsers. The author recognizes that you cannot avoid eval() in this case, but it's not a mystery why: because it's not Json anymore, and calling it Json causes confusion, much like $array = new stdClass(); and other obfuscated code.

December 18: You Don't Need All That
Classes are slow! MVC is even slower! Real men do not use autoloading! We should stick to require_once(). The best part?

Or, put some effort into writing more general, commonly-used classes rather than lots of little ones.

Never, ever, heard of Single Responsibility Principle? Cohesion? Decoupling? That design should not be driven by how fast including source files will be? I actually refactor every class that surpasses 400-500 lines of code.
If you're thinking to follow the advice of discarding autoloading, maybe you'd like to know that PEAR 2 will drop require_once() statements. As for the post, if you do not believe me as a source of information, Roman Borschel, the lead developer of Doctrine 2, says:

@giorgiosironi agreed. complete crap. Another meaningless artificial benchmark. Not even with repro code. that post is a big #fail.

There are very valid posts in this year's PHP Advent, but these hidden "gems" are dangerous and I wonder why no feedback is accepted. Open discussion would benefit the community more than lectures on php practices.