The main reason why programs can't always be run off of an SD memory card is that the mechanism for accessing data on an SD card is completely different from the mechanism for accessing data in internal memory. Essentially, when Palm OS first came out, it was designed to work on small devices which only used RAM for storage and were primarily supposed to act as organizers; consequently, the Palm OS file storage system was designed specifically around that.
On most computers, data files are accessed sort of like an audio or video tape; you "fast-forward" or "rewind" to the place in the file you want to begin reading or writing data, then "play" or "record" to read data from the file or write data to it. On Palm, however, data files are more like a deck of flashcards; you retrieve data by finding the particular card you want, and you write data by either writing some more stuff on the card or by inserting a new card into the deck. This is actually a very efficient and time-saving approach if all you're trying to do is organize a few hundred or a few thousand contacts/appointments/notes/etc, but for various reasons it becomes extremely inefficient when you're trying to work with more than a few thousand "cards" at once, and because you can only fit a limited amount of data on each "card", it can be rather awkward and inelegant when you're trying to store something long and complicated like an MP3 file. (imagine trying to write a novel on a stack of index cards)
Anyway, when Palm added support for add-on memory cards in Palm OS 4.0, they abandoned this system and switched to the more conventional fast-forward/rewind model, both because the old system was no longer efficient and because they wanted to be able to work with files in standard data formats like JPEG, MP3, etc. However, this required them to roll out a completely different interface for manipulating files on memory cards than the one that was used for files in internal memory. Since the thousands of existing Palm OS applications were all built to use the older system, they kept it in place for internal memory and restricted the newer system to add-on memory cards only. But any application that wanted to read/write data from an SD card would have to be heavily redesigned in order to be able to do so. And since a lot of programs' data formats had been optimized around accessing data in that "index card" format, in a lot of cases (including our own software, prior to the release of PlecoDict with its spiffy new data caching system), even after an application had been altered to read/write data on SD cards, actually doing so would often slow it down to the point where it would become almost unusable. Making matters worse still was the fact that Palm hadn't actually done a very good job with implementing this new file system, and it lacked the data caching and other performance optimizations that you might find on another system like Linux or WinCE.
So basically, in most cases applications won't work on SD cards due to a combination of programmer laziness and performance issues. Incidentally, this distinction in file formats is also why you still can't install text files, MP3s, etc, directly into a Palm's internal memory, at least not without converting them to .pdb first - the Palm file storaqge system will only work with files that are cut up to work as "index cards" and can't accommodate any other type of file. .pdbs can be stored on SD cards because that conversion is much simpler - the data on the "index cards" is simply written out in order as one big block of data.
Regarding our software specifically, the reason why neither of our handwriting recognizers has been able to run from an SD card is because the companies we licensed them from didn't bother designing them to do so. The vast majority of their sales/licenses are to OEMs and hardware distributors that want to build a Chinese handwriting recognizer right into their PDA/smartphone; there's no need for an SD card version in those cases, and the comparatively tiny percentage of their sales that come from add-on software vendors like Pleco are insufficient to justify the (rather sizable) programming effort that would be needed to enable SD card support.
As for the flashcards / user dictionaries not working, this was mostly the result of a stupid design decision on my part - Oxford Dict had used something like half a dozen different file formats for its various data files, and I was insistent that PlecoDict would use one and only one format for every single file, even on different platforms. The problem with this was that it necessitated designing all of PlecoDict's data files around that old Palm file format, since that was the only way the data files could work both in a Palm's internal memory and on an SD card. This actually worked quite well for read-only data files, we'd simply find the particular "index card" we needed and load its contents into memory and the result wasn't really any less efficient than most database storage systems, but it became very problematic with editable data files like flashcards - so much so, in fact, that we ended up having to change the format on Pocket PC and store flashcards / user dictionary entries as ".peb" files instead. In Pleco 2.0, we'll still use the same format for read-only files (since we've spent a lot of time developing it and it really does work pretty well), but we'll be using a new format for editable files that will allow us to easily write data to an SD card on Palm (while only slightly reducing performance in Palm internal memory, which should be more than made up for by the fact that we're adding accelerated code for ARM processors).
