we prefer to think of it as a "don't reduce my box to a ball of molten goo"
policy, but that may just be semantics

I think the reason for this policy is that the folks who originally developed
yum (me) and still develop yum are sysadmins, for the most part. We value
stability and consistency from the tools more than whizbang action. We also,
from our years of experience, have determined that while there are users who
want to do as much as possible and damn the consequences that most users like
for their systems to not explode.

as a general rule I'd say:
yum --enablerepo=extras install '*' is an extraordinarily bad idea.
I'm closing this wontfix, there may be ways around this problem in the future
but I doubt we'll ever enable a 'breakmysystem' option.

I don't find these arguments to be realistic, and certainly not persuasive. 
They are generalities, not specific.  One must imagine that these arguments rely
upon hidden components - superstition, or job security, or windows sysadmin
experience.

What do you expect to happen with "install '*'", really?  What does "molten goo"
actually mean here?  It sounds kewal, but hides a rather trivial result, I think.

Only where a package installation implies some kind of arogant "set as the
default file/application" could there be any actual conflict.  Basically, a
package would have to overwrite a configuration file, or worse, write files with
filenames already being used by other packages.  This would be fundamentally
broken behavior on its face, a fundamental problem with the package, not having
anything to do with the package manager.  The only practical examples of this I
can think of are the proprietary Nvidia drivers that overwrite the gl libraries
with incompatible versions, which is to say, use the same filename for a
completely different kind of file, and certain RedHat libraries, that use the
same filename for different CPU specific files.  But hey, this isn't MS windows
we are talking about, and arogantly overwriting other package's files are why
proprietary drivers are not allowed in general distribution.

Unless the intent is to allow or even promote this "won't play nicely with
others" package behavior - proprietary Fedora? - there is no excuse for
crippling the package manager.

BTW - doh! - simply using the "exclude" option in the yum configuration file can
go a long way to resolving any system-specific dependency concerns.  So a simple
compromise feature for yum - though maybe not so simple to implement - would be
for yum to print a suggested set of "exclude" statements which would resolve the
dependency errors and allow installation to procede, possibly in the form

 exclude <A>  OR exclude <B>
 exclude <C>

This format would probably be easier for the user to understand, and would
continue to allow the sysadmin to decide what does and doesn't get installed.

What do you think?

1. you know --exclude is an option you can pass on the commandline, too.
2. it's not always obvious what's the best path to exclude.