I agree. There is no reason why html_errors should be off in any case. Especially because the reasoning is non-sense.

Is a dynamic plain text web page that hard to imagine? What about non browser 
output? I know the CLI SAPI has html_errors = 0 hard coded in but why force people 
to turn off an option that provides little to no benefit...

sorry, I can't follow you.
"Is a dynamic plain text web page that hard to imagine?"
no, but the majority of the php sites out there use html as the primary output 
type.
you can turn off the html_errors if you are dealing with plain text files.

"I know the CLI SAPI has html_errors = 0 hard coded in but why force people 
to turn off an option that provides little to no benefit..."
so only the apache SAPI would be affected, where the majority of the users use 
html output.

but I think that this option should affect anything in a production system, 
because you turn off the error_reporting in production (and PHP also suggests 
that, so any distribution which follows the suggestions of the php.ini-* files 
wouldn't be affected by this change. at all)

and both error_reporting and html_errors is enabled in the php.ini-development, 
so for the text/plain people that would be a problem also.

Tyrael

probably you know, but you can re-enable html_errors for cli via ini_set:
http://www.php.net/manual/en/features.commandline.differences.php
for example:
php -d display_errors=1 -d error_reporting=-1 -r 'ini_set("html_errors", 
1);trigger_error("foo", E_USER_NOTICE);'

Tyrael

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

fixed in 5.4:
https://wiki.php.net/rfc/error-formatting-for-developers
http://svn.php.net/viewvc?view=revision&revision=314761