Two reasons: economies of scale, and Steve Jobs is an ass.

Apple can get good pricing because when they order a component and the manufacturer asks how many units they'd like, the answer is often "all of them." Apple doesn't usually get all of them, but they get a large percentage of the total manufacturing capacity of the vendor, they sometimes source from multiple vendors, and they still can't keep up with demand.

And, when Steve Jobs gets an answer he doesn't like, he doesn't just give up, he fights. He fought the record companies until they were willing to sell music online without DRM; he fought Verizon until they were willing to sell an iPhone without loading it full of crap and disabling half the features; fighting component vendors until they give the best possible price is an amusing diversion.

The original iPod shipped with a 5GB hard drive. At the time, digital cameras used exactly the same kind of hard drive. Photographers quickly figured this out and started buying iPods as fast as they could get their hands on them, because the full retail price of an iPod was cheaper than anywhere else they could buy a 5GB hard drive for their cameras. Jobs had to fight pretty hard to get the kind of pricing that would let Apple do that.

We have.

You're not wrong. However, if enforcing TLS becomes commonplace, I'm sure the next step will be to start doing certificate validation.

6) Configure your server to identify itself by the same hostname that your reverse DNS points to (and, obviously, be sure that you have an A record for that hostname that points to your IP address).

My diagnosis is slightly different: in fact he does have perfectly valid reverse DNS (71.178.232.50 resolves to static-71-178-232-50.washdc.fios.verizon.net which resolves back to 71.178.232.50), but it's his mail server that is misconfigured to identify itself as "localhost.localdomain". That's what looks suspicious, not his reverse DNS. I would recommend either:

1) Configure his mail server to identify itself as the hostname that his IP address resolves to (static-71-178-232-50.washdc.fios.verizon.net), or

2) Ask Verizon to set up custom reverse DNS for him, and configure his mail server to identify itself with that hostname. This is prettier, but technically no more valid than option 1, which would require no help from his ISP.

(And yeah, he has extra MX records. Some spammers will skip straight to the last one; legitimate MTAs should try them in preference order, lowest to highest, so this could mean if there's a failure, MTAs will try his server three times before falling back to Google, but some implementations may be smart enough to recognize all three as the same host and skip to Google on the second try. I wouldn't personally set it up this way, but I'm not gonna recommend changing it without asking him why he chose to set it up this way.)

Sorry, but I disagree. I strongly support residential ISPs that block outbound port 25. My preference would be, if you have a static IP address (which may cost a little extra, which I'm also fine with) they should unblock port 25 upon request (for no additional fee, but only upon request, not by default).

Yeah, it's an extra hoop to jump through if you want to run your own mail server. I run my own mail server, and that's precisely why I want outbound port 25 to be blocked by default: I have to deal with spam coming from all the ISPs that don't do this.

And no, this shouldn't affect end users, because end users should be using 587 or 465, not 25. It's not 1998 anymore.

STARTTLS has been around for awhile now. Are you sure that "most" servers don't support it?

A lot of larger financial institutions are even beginning to require other companies they do business with to enforce TLS encryption when communicating with them (so, for example, if you do business with JP Morgan/Chase, they want you to configure your outgoing SMTP server to refuse to deliver mail to JPMC's servers if a TLS connection fails, bouncing the message to the sender instead of falling back to plain text).

I'm confused by what you're asking for. Are you implying that no configuration is required for a serial interface, and therefore the need to configure iDRAC/iLO/Raritan makes this type of solution unsuitable? Are you suggesting that you can connect remotely to a serial interface without having a functioning network? Are you saying that a serial solution doesn't take up any rack space?

I have no idea what the pricing is, but I would expect a serial solution to be cheaper, and to work better over high-latency connections. Those are valid reasons to prefer serial over the alternatives I suggested.

Dell iDRAC, Raritan KVM-over-IP.

Credit cards (or debit cards used as credit cards) do not use a PIN, and now at many places (pay-at-the-pump gas stations, fast food restaurants) don't require a signature either. It's one-factor authentication; if you physically possess the card, you're authorized to make the transaction.