Let me dissect the the "key design issues", I think this is the 5th time I've done this, but I'll bite yet again.
Crippled C++ support: Exceptions are supported, they have been for YEARS. You'd be hard pressed to find a Symbian phone out there that doesn't have exceptions. If you want STL then port it, I once had the set of STL I needed with a basic STLPort port - this was several years ago. Certainly when ROM/RAM space is tight STL is going to get in your way - Symbian enabled smartphone applications years before the high performance processors and huge amounts of RAM todays phones have.
Confusing and limited string handling: Even the author admits they don't know what they are talking about "The reason was apparently to save a few bytes on each string". A descriptor is a very simple concept, a "description" of a contiguous memory region. TBuf8 is a descriptor to an in place buffer (ala a C array), a TPtrC8 is a constant pointer to specified region of memory, they all have a common TDesC8 base class. Plus if you want a "proper" string class, then make one - then spend a few minutes understanding the subject matter to realize a TPtrC8 cast operator on the class will magically enable your class to work with the Symbian APIs.
Limited support for multi-threading: Symbian is fully preemptive multi-tasking (check out RThread, wow, I guess the author missed that)! Even the kernel is preemptive (hence being sufficiently real-time to implement a baseband on the application processor). Just because Active Objects exist doesn't mean they are the only things for multi-tasking. Hopefully now the code is out in the open you can see how the experts use them to implement asynchronous code without having to always be thinking in terms of locks.
Bad development environment: Well this is a fairly subjective subject - I haven't had any trouble, install SDK, install Carbide and start developing. I can only imagine how taxing this must be for someone who appears to know so much.
It might not be as "easy" to develop on Symbian, but it is worth being thoughtful in writing tight, low overhead code (which the Symbian APIs are all about). It's easy to throw CPU and memory at problems, something which programmers are too willing to do these days.