Isn't that you can write anything to boot it, that part is fine, its the fact that it adds complexity and leads to more failures, at least from what I've seen.

Being a repairman and system builder I tend to see more than your average Joe and what I've found is that screw ups that would simply require a CMOS reset in BIOS will leave a cooked board with UEFI. For example power here can often get iffy, with line sags and brown outs and while the BIOS boards will often handle it fine or at worse need a reset the UEFI boards? Tend to cook.

At first I just thought "Well its the new tech, DDR3, more cores, thinner traces, blah blah blah" but then I happened to get a hold of some Biostar and Asrock boards from the transition where pretty much the ONLY difference between board A and board B was that board A was BIOS and board B was UEFI and guess what? The BIOS boards are still going strong, the last of the UEFI systems will be brought back day after tomorrow and from the sounds of it it'll be joining the others in the dumpster.

Now as to the "why" I don't know,maybe there is a problem with the UEFI chips, maybe they just have insanely low tolerances, hell if I know, all I know is when I run out of BIOS boards I'm gonna end up having to buy spares of every damn board i buy because the UEFI ones just don't seem to work as well, at least that is what I've seen,YMMV.

If you look at the technical side of things, UEFI, is light years better. BIOS is kind of held together by bailing wire, gum, and electrical tape. But, its old as dirt so everyone knows how to deal with it. UEFI, is just staring to get seriously used, and has a low barrier to entry ( as evidenced by this article). So its going to take a while for people to figure out how to do it right, and problems to avoid. I only know a little of the software side, not sure how complex it is hardware wise, but it is different. I have not otherwise heard of problems with UEFI boards hardware. Mostly just stupid implementations, like the Samsung bug that allowed you to brick it by writing a variable to UEFI memory.

There should currently be no hardware differences between "BIOS motherboard" and "UEFI motherboard". The only difference is what data the manufacturer felt like storing in the flash ROM.

My guess is that you're not a large enough statistical sample, and were just unlucky. I flipped a coin 10 times and it came up "heads" 7 times, therefore there must be a secret government plot to make one side of the coin heavier and the other lighter to influence the results. ;-)

In this case, there is a logic explanation other than just random chance: the added UEFI complexity.

See, motherboards manufactures needs to maintain large product portfolios, with fast release cycles. Overburdened engineering teams is pretty much the norm in this industry.

The BIOS is a far more simple kind of software, adapting it to new products is far more trivial than with UEFI. And even with BIOS, there is bugs, lots of it.

Most manufacturers took near a decade just to deliver a descent ACPI implementation, let's not even speak about slight more complex stuff, like virtualization support, hot-swappable storage, USB mass-storage boot, RAID, decent PXE support... and goes on.

Now, the manufacturers needs to mobilize their already spread thin engineering teams to adapt UEFI code, what is, in effect, almost a operating system by itself. The final result is obvious: far more bugs, in particular for cheaper low-end motherboards, that gets lower development budgets.

UEFI is one of these things that looks gorgeous on paper, but in practice it is a invitation to a disaster.

I'm pretty sure that most implementations out there is so screwed up that every single one would be very easy to exploit if you can override the operating system safeness. I can even point a easy entry point: these applications to fully manage the motherboard from the OS.