I should qualify that statement by saying that there are a lot of points in PalmOS's favor: as someone who got started programming C for the platform, I have fond memories of versions 3 and 4. Indeed, at the time, PalmOS was well-designed for the challenges it faced. Unlike Windows CE (which ports a subset of the Win32 API to embedded platforms), it was meant specifically to run on very low-end (read: cheap) hardware while still responding quickly. It did this through an event-driven application model that put the processor to sleep as often as possible, as well as a GUI that faked multitasking by having programs remember their state and relaunch in the same place. API calls were, as far as I remember, pretty much just bare pointers to functions in ROM, and you could patch the system traps with your own code to extend OS functionality, like fixing the anemic clipboard or adding pull-down menus.
Much like the Newton, PalmOS didn't have "files" in the traditional sense. All data on the device, including applications, was stored as records inside databases. Inside applications, GUI layouts and components were stored as entries alongside records containing binary code, making it an interesting platform to hack. On both platforms, it soon became obvious that while this is an interesting idea that provides some advantages, people have a lot of files that don't naturally fit into database records, and flat file support was bolted on. Unlike the Newton, Palm didn't try to implement full handwriting recognition, which is troublesome on mobile platforms for several reasons: the device is too small to write comfortably, parsing handwriting requires a lot of processing power, and it invariably fails in the face of chicken scrawl. Instead, they went with Graffiti, a set of simplified letter shapes users had to learn--this sounds cumbersome, but it worked surprisingly well. To this day, I can still write in Graffiti almost as fast as I can scribble longhand.
Palm made choices, in other words, aimed directly at creating a device for quick data lookup and entry. It was never meant as a multi-use mobile computer. And as time moved on, and users began to expect more out of mobile, that became increasingly obvious. The problem Palm faced was two-fold: it didn't want to leave behind the tens of thousands of useful programs that were the platform's greatest strength, but the underlying framework had been stretched the point of breaking.
The solution they created, comically, was to write a modern OS devoted almost entirely to emulating the old operating system. The PalmOS devices that you buy in a store nowadays do just this: programs are compiled for the Dragonball processor (with possible chunks of the binary in native ARM code), then run in a virtual machine with holes poked into it for networking and graphics. It's actually kind of brilliant, in a twisted way--like Java, if Java had been designed by old Apple hardware nuts instead of computer science professors. They've even made a VM for Nokia's Internet tablets, and another company has ported emulators to Windows Mobile, Symbian, and OS X Mobile, raising the very real possibility that classic PalmOS could actually become a defacto interplatform standard (a task for which, honestly, it's not badly suited--or, at least, could hardly be worse than Java's MIDP/CLDC mess).