Out of curiosity, do you have a reference for that? There seems to be a lot of confusion regarding that "incompatibility". The Macintosh Plus is generally considered "completely" compatible with the original Macintosh to the extent that it's capable of running all the original applications and operating system versions when booted from the appropriate disks. There *is* a small body of software that's incompatible with the System software versions introduced with the HD-20 and Macintosh Plus (IE, the ones with hard disk and HFS support), but that's not the same thing as being incompatible with the 128K /ROMS/. If you pretended you just had a floppies and booted from a disk said software *would* work with a Plus. Does anyone know a true counterexample? (There may be something that chokes on the slightly different way the Plus indicates how much free RAM it has, but I haven't heard of it.)
It guess it *is* true that the drivers for some of the previous third-party efforts (Hyperdrive, et al) that used MFS and oddball partitioning schemes with older System versions *did* work with some of those troublesome programs to get them to run off mass storage. In principle you could write a similar driver to run the Plus' SCSI subsystem the same way, I guess, but you'd really have to *love* one of those programs.
Coincidentally, here's a rambling thread over on Applefritter where the issue of drivers for third-party mass storage systems was uselessly debated. I made the gruesome suggestion over there that one thing that *might* be worth investigating is hacking the ".sony" driver the same way as is done in the BasiliskII and Vmac emulators. Said driver in these emulators replaces the low-level IWM driver in the Mac's ROM with a driver that transparently handles arbitrarily-sized disk images. (Meaning that you can map a "hard disk-sized" filesystem into the Mac OS without worrying about emulating SCSI controller hardware.) It seems to me that it would be relatively trivial to convert this concept to hardware by putting a piggyback board into the ROM sockets which contained a small block of SRAM to replace the ROMs and a microcontroller to handle a flash storage. On powerup the piggyback board would load the SRAM with a copy of the Mac ROM (64k or 128k, wouldn't matter, you could easily switch between them for that matter) patched with a new .sony driver which pointed at the microcontroller, write protect it, and then allowed the Mac to boot off the disk image of your choice.
(You could write a small Mac application to present an interface for switching between images on the memory card at runtime, with an initial config file written to the card from the host computer used to generate the images. Many microcontrollers have FAT/VFAT filesystem parsers available in their example code libraries so it should be easy to handle the disk images.)
Without some creative noodling you'd lose the floppy drive controller when running a modded ROM, but it seems like a fairly small price to pay. The only software which would get broken by doing something like this is anything that reads a disk by bitbanging directly on the floppy controller... the same sort of software that would be broken by running it in an emulator, but the Apple disk controller was so deviously complicated and software dependent I'd hope that would be a smaller category than software broken by HFS.