Here's my reading of the tea leaves. . .
By the time SD cards came out, both Fat 16 and Fat 32 were already in common use for hard and floppy drives. The reading software for both formats debugged, and was (probably) written to separate the physical I/O code (that actually sends/receives the read/write hardware interface) from the logical Fat processing code, once again (probably) with the I/O module sending a flag back (telling it what format is was) to the logical processing code.
Maybe they got fancy and only used Fat 32 code, and had the I/O routine automatically blow zeros through the high order bits on the address. That way you only have one Fat (Fat 32) logical block of code. <Shrug>
That's how I would have designed it, to make it as hardware "independent" as possible.
Remember, the chip reader manufacturers were building "cheap and quick" in a low margin business. The manufacturers had to meet the SDHC spec, nothing said <how> they had to do it. If it was cheaper and safer to just blow high zeros in the addressing and do everything as Fat 32, they'd do it. especially if they offered low level firmware with the reader hardware, and would customize the interface to the gadget firmware cheap.
Nor would most gadget manufacturers care, if it worked with SDHC, was available fast and cheap, and was reliable, they were happy. Only high end companies, who were willing to pay to control every piece of software in their systems, would embed the SDHC limits in their firmware.
ExFat, was a separate format, <and it cost a separate fee>, that initially most gadget makers wouldn't pay for. now, of course, everybody does. It has advantages over Fat 32, but that doesn't matter is your hardware won't read it. . . .
If you look at the connector on an SD card, SDHC card, and an ExFat card, they are the same. . .