Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
As always security is a trade-off. The threat vector of flashing a backdoored BIOS/firmware is irrelevant for 99% of the market: most people will never be targets of such highly-technical attacks.
PS: I tip my hat off to Sprite_TM; fascinating research! I love to disassemble firmware myself :) I liked how you were able to reverse-engineer the data structures in RAM.
Adding security to a system imposes costs on the use, maintenance, and support of those systems. Can you imagine the scale issues associated with maintaining PKI over the millions of devices deployed? How about hundreds of millions?
TPM is present in many, many laptops yet most IT departments leave it un-configured. Why? Because when you replace the hard drive and it changes the boot vector parameters, the machine will no longer boot and you have to work inside the auth mechanisms of the TPM infrastructure do to simple hard drive replacements. (nb: I'm not an IT guy so I might be a bit off here, but you get the gist)
So the reasons for NOT including security are pretty damn big compared to the risk. As security guys are fond of saying: "If I can get physical access to your machine, all bets are off." Keyloggers, evil maid BIOS, HID attacks, firmware attacks on peripherals, etc are all possible ways to compromise a device. If you're wondering how STUXNET got into an air-gapped security facility in Iran, I'd bet that a method like this was the prime candidate. That's how I'd do it.
This lets you play "backups" of games, enabling piracy. It doesn't let you run unsigned code (those required other cracks) or sign anything (such as save files).
Now, security is a process. You can expect breaches of high value hardware, and need to react to them.
The security model for consoles STARTS with the assumption that the attacker has physical possession of the hardware. This makes things interesting; it's certainly a big differentiator for PCs versus tablets, and one of the reasons why the Windows group at Microsoft has had a lot of trouble making their stuff secure on non-PCs.
But for a hard drive, things should be pretty contained. I estimated it would have taken a couple of weeks to secure one major embedded system I worked on; assuming the interfaces are limited, it's not a huge deal.
These features are required by enterprise customers to prevent just this sort of tampering.
E.g. the FOSS community wasn't a fan of only-trusted-secure-boot when it was microsoft holding the keys and the source and releasing neither.
Secure boot isn't a technical solution to a soft/firmware update problem. It's a control mechanism to solve a management problem. Crazy idea, don't put the interface that has access to firmware on the standard interface. Use its own interface and allow motherboard manufacturers to support it for enterprise/datacenter geared systems.
This stuff /is/ hard. I sat next to a bunch of folks doing this on a console platform and the techniques and exploits were, in a word, breathtaking. But if you know what you're doing and your scope is limited -- to a smallish device, for instance -- you can make it very hard for someone to crack.