Content is not PHP. Code is not content. Content is text; PHP is logic. Hell, we could probably store the whole of Drupal in the database, and add a few small files to eval it.
Why is that not the case? Because we want to maintain a separation between logic and code.
PHP is always *executable code* but it is not always *logic*. At least, no more than HTML or XML. Many times in Drupal, it's just a shortcut to printing the particular content that an admin wants/needs on a page. The .inc file solution is fine for *completely custom* php driven pages, but it doesn't help on other kinds of pages that currently have one-line php calls to display dynamic information. PHP snippets in key areas -- blocks, pages, and block visibility checks -- have allowed sites to Get Things Done With Drupal without diving in and writing custom modules for every niggling tweak. It's one of the things that makes Drupal a lot more powerful and flexible. Until the arrival of views.module, it was the only way for most users to get customized listings of content. That's pretty basic. We need to recognize that for MANY sites, this will be a crippling downgrade.
Besides these philosophical reasons, php input is just a real big security hole. It is not about shooting in your own foot. But about people like bryght etc handing out guns to let people shoot bryght in the foot. Just for fun: try securing your site, by imagining an administrator that you do not trust. Its near impossible! that adminstrator can hardly administer anything, because you have to close so many backdoors, all related to PHP input that there is hardly anything left adminstrating.
That's understandable. I can see the case for turning PHP Filtering into a separate module, leaving it disabled by default, and restricting it to user 1. While the .inc file solution is technically cool, it is still a blow to core functionality. --Jeff