So, uhm...
"In other words, the user can only be sure that their connection to the interception product is legit, but has no idea whether the rest of the communication – to the web server, over the internet – is secure or has been compromised."
I think it boils down to a very basic issue once more: understand what the heck you're doing. Most modern operating systems (Windows Server, *BSD and even Linux) provide several tools which you can use to check connections and the state their in. Obviously it is sometimes preferable to do outside checks (like with port scans) but even that can be done by utilizing a second server (for example).
The main problem? Simple: you have to know what the heck you're doing. You need a basic underlying understanding of the encryption process, how to monitor network connections (I've come across too many people who had no clue how to use tcpdump or netcat for example) and interpret the results.
And that seems a bit too much for more "modern" companies, time is also money afterall, so they'd rather rely on out-of-the-box ready to use gizmo's like these. Without stopping to think about possible consequences.
Welcome to the modern world of ICT: where a lot of people stopped to think for themselves, don't bother to try and understand (learn) something new and where you totally rely on what others tell you without questioning nor challenging them.
PS: Doesn't this same risk apply when your HTTPS connection is using a reverse proxy (as suggested by an article some weeks ago)?