agreed, for the most part
The one advantage of a hardware RAID (if integrated with a proper/compatible chassis) is failure LED's. This is somewhat difficult to get from a software RAID on a plain HBA.
At the low end, you need a disk enclosure/backplane with either SGPIO (combine with Adaptec, Areca or just about anything recent with SFF-8087) or with discrete "failure" signals, one per drive (combine with any Areca controller).
As for firmware continuity, Adaptec AACRAID used to be my favourite during several years, but in the recent years Areca has taken over their crown. Replace a controller with something you find in your dusty stock of spare parts - well that's where the fun begins :-)
Swapping cables around has never been a problem on any HW RAID. One recent experience, with a SAS-based Areca: I built an array in a 24bay external box (attached to an Areca RAID). Then I powered down the box, added another external JBOD, and scattered the drives between the two enclosures. Powered up, and voila, no problem - Areca combined all the drives correctly, from the two enclosures. Or another example: build a RAID in one 24bay enclosure, and then plug in another external SAS enclousure at runtime. No problem - enclosure detected, drives enumerated, ready to configure another RAID volume or whatever...
A quiz question: suppose you buy a new server with two drives in an Adaptec (AACRAID) mirror. Before installing your production OS, you try some recovery exercises, to see how the firmware works. You set up a mirror in the Adaptec firmware, you install an OS maybe, you remove a drive from the mirror and insert another one, to see what it takes to rebuild the mirror. The rebuild goes on just fine. You go ahead with the OS install and turn that into a production machine. You remember to "erase" the drive that you initially pulled, when testing the hot-swap: to be precise, you plug it alone into the Adaptec RAID controller once again, and remove the degraded array stump. Then you plug back your two production drives (the mirror), and put that "cleared" drive aside. After two years, one of the production drives fail - so you fumble in your drawer, produce the spare drive, plug it in, maybe a powercycle... and voila: *the production mirror array is gone* ! Explanation: the recentmost configuration change, logged on the drives, happend to be the array removal on your "spare" drive...
Otherwise I agree that for Linux it doesn't make much sense to buy a HW RAID just to mirror two drives to boot from. If you know your way through the install on a mirror, and maybe to install grub manually from a live CD, and especially if you don't plan to spend money on a proper hot-swap enclosure (so that failure LEDs are not an issue either), the Linux native SW RAID will prove similarly useful as any HW RAID firmware. For Windows users willing to spend some money on hot-swap comfort, I tend to suggest the dual-port ARC-1200 with some SAS series enclosure by Chieftec = the ones coming with workable failure LED's (the ARC-1200 is SATA-only).
As for parity-based SW RAID on Linux: if you can find it in dmesg, the MD RAID module does print a simple benchmark of several alternative parity calculation back-ends (plain CPU ALU, MMX, SSE etc) and picks the speediest one. And the reported MBps figure has been well into the GBps area for ages (since the PIII times). 3 GBps on a single core are not a problem - corresponding to 100% CPU utilization for that core.
For most practical purposes though, you'll be limited by your spindles' (drives') random seek capability. This is about 75 IOps for the basic desktop SATA drives. That is typically the bottleneck with FS-oriented operations. In such a scenario, you won't get anywhere near a HW RAID's CPU throughput limit. And yes, OS-based buffers / disk cache can sometimes help there - provided that you can configure the kernel's VM+iosched to make use of all the RAM (speaking of Linux that is).