Definitely not.  This is the only thing that allows someone to enforce a server-wide security policy on questionable code.  And yes, it is magic_quotes-like, but it is magic_quotes done right.

Having code be responsible for its own filtering has demonstrably failed miserably.  With a default filter you have what I like to call a data firewall, much like a network firewall.  You filter everything by default and then poke holes in that data firewall from your application.  The traditional approach of letting everything through and then trying to remember to apply filters in the right places simply doesn't work.  

There should also be very few places where you need the raw user data.  You should document those places so security-aware users can audit and apply their own data security in those places.

While I see your point, since each server will have it's own "firewall" or even not one at all, this does not solve the problem because there is no consistancy across servers.
Programmers who fail to check whether there is a default filter or not, or even server administrators who don't even know the option is there can still unwittingly create security holes, while the few who do will most likely be in the minority.
This then punishes good programmers for doing things right, but allows irresponsible or lazy programmers and administrators to punch huge holes in your "firewall" without even realising it.
I am not suggesting that the filtering of GET, POST etc. be disabled, I am merely suggesting that it not be configurable, and the same filtering is applied consistently, say "special_chars", in order that your "firewall" is actually there, programmers know that it will be there, and it is providing a measure of security against common attacks, such as SQL injection.

I would love to turn it on by default, but I missed the boat on that by some 10+ years.  At this point we can't do that.  The best we can do is give administrators the ability to do this.  

It depends a bit on which side of the fence you are watching this from.  For companies deploying many different applications on their servers, this option is invaluable.  They can apply their own company-specific set of filters, deploy the various applications and go through and fix the few places that may break because they were not aware of the filter.  Failing safely is the goal here and saying it doesn't solve the problem is untrue.  It solves the problem for that company and for the admin who knows what he is doing.  So, we aren't punishing people who know what they are doing on that side of the fence, we are giving them a much needed tool.

On the other side of the fence, for someone writing portable software to run in as many environments as possible, it is more work, you are right, because you have one more difference to worry about.  It is no harder to deal with than the magic_quotes situation though, and since that is now gone, we have swapped a rather useless option you need to worry about for a useful option, that you still need to worry about.

Is this not something to consider enabling by default for PHP 6 then, seeing as a lot of backwards compatibility is being broken already, why not make some necessary changes such as this?