I have never done any iPhone development, but I'd like to point out a few developments in the Symbian world which relate to some of your points:
Symbian C++ vs Objective C - the former is yuck IMHO.
It's certainly not to everyone's taste! For application development, Symbian C++ is going to become less and less relevant, as Qt (which is generally regarded as a very user friendly set of libraries) will be used for the next generation of the application framework / UI layers. The lower layers of the OS will continue to use the Symbian dialect of C++, but Qt libraries for functionality such as multimedia, location and messaging are being added - so app developers are unlikely to have to directly call native platform APIs.
emulator - how close is the emulator
to the real device - the Symbian
emulator is really a simulator as it
Symbian libraries modified to run on
Win32. E.g. a process is a thread on
the Symbian emulator and not a Symbian
process. The emulator is a separate
build target.
Your description of the emulator (single host process, separate build target) is correct. Because of this, the emulator is essentially a port of the OS to a completely different platform (in this case x86), so does not model a phone closely at all. Happily, it is being phased out and replaced with a simulator, like those already included in the iPhone and Android SDKs. (In fact, the simulator is based on the same technology - QEMU - used by Android) Because the simulator translates ARM instructions into those understood by the desktop machine, the same binaries can be deployed to both the simulator and onto the device itself.
The simulator includes a "board model" consisting of a number of virtual peripherals, each of which maps part of the host machine - so for example the simulator audio device may be hooked up to the desktop sound card. Because this board model can be modified, the simulator environment can be tailored to very closely model a particular device, so expect to see device manufacturers ship a simulator in their SDK which closely resembles the corresponding physical device.
IDEs - how do they compare (e.g.
eclipse or codewarrior vs relevant
iPhone IDE)
CodeWarrior is a pretty old and rather creaky IDE. Carbide (which is based on Eclipse) is better, and offers reasonably mature on-device debugging support (although not as slick at the XCode / iPhone solution). The IDE included in all Qt SDKs (Qt Creator) is probably the nicest, and has been compared to XCode in terms of usability.
fragmentation - There are many Symbian
OS versions and phones that can can
potential target - this can be a real
development and maintenance nightmare.
Plus various flavours of UI.
Definitely true in the past. Hopefully getting better in future. Where there were once multiple UIs (S60, S80 and UIQ), there is now just one (currently S60-based; about to be replaced with a Qt-based UI).