Moomalade

I’ve used both ColladaDOM and FCollada for working with Collada documents.
Which one is better can be subjective and is dependant on so many different variables, but comparisons from experience can sometimes be useful.

To cut to the chase I’d say you’re better off with ColladaDOM in general, or FCollada if you want a supported commercial solution.

ColladaDOM
ColladaDOM is a framework with an interface generated directly from the Collada XML Schema. This locks the interface to a specific version of Collada. Note, you can still have multiple ColladaDOM’s in your code if you don’t mind modifying the code to namespace it by version, or use DLL hot loading.

I think of ColladaDOM as a strongly typed XML document interface with an entity interface sitting on top. You can access ColladaDOM using the entity API which wraps the underlying framework, or just talk straight to the underlying framework. If you’re writing documents (rather than just reading them) then you need to understand the underlying framework anyway.

The entity API can be more convenient in many places but it’s a shame that the writing process isn’t the obvious logical inverse of the reading process.

FCollada
FCollada excels because it supports more than one version of Collada, and provides a consistent API for reading and writing Collada documents.
It has utility code to manipulate the scene graph such as normalizing the up-axis and unit lengths among nodes.
The few bugs I’ve found existed in the utility code and are easily fixed. The latest version is test with VS2005, but can also be quickly ported back to VS2003 by removing the need for the elipsis (…) in the preprocessor macros.
FCollada is unsupported in open source form, but you can pay Feeling Software for support and features which may be invaluable for you.

Comparison
At the top level, FCollada is more traditional and easily understood allowing you to get going faster, while ColladaDOM requires more up front learning, but ends up feeling more flexible as a result (in terms of how you can traverse and process data).

I wouldn’t say one is simpler than the other though. Once you’re passed the top level scene traveral you’re dealing with the exactly the same Collada data specification in both libraries. There’s no way around that, and they’re presented in pretty much indentical ways.
Collada represents things a particular way and you’re going to have to write that thunking layer to get that data into a useful format for your application or tools whichever you choose.

If you think ColladaDOM looks looks complex, it’s probably because the Collada schema is complex and you’ll likely run into those same complexities in FCollada at some point, it’s just ColladaDOM throws you in the deep end.

Conclusion
Most recently I used FCollada, but I personally like ColladaDOM. If the company I was working for at the time didn’t have an FCollada support contract I’d go with ColladaDOM on a new project and pull my experience to write the extra useful tools that FCollada affords. Although I’d likely punt on a few of them until they were actually required.

Update 27th October 2008
Looking back, I think pushed towards ColladaDOM as it felt like the more technically “right” solution. It would be good for many ColladaDOM conditioning processes, similar to FCollada’s tools, to be available, and linkable with an asset pipeline.

Update 20th November 2008
Feeling Software have announced Feeling Speedy, which is a faster binary version of the FCollada tool set, with the ability to interchange between binary and text versions. If you want a commercial solution, the extra speed afforded for loading large collada documents might make FCollada a no-brainer choice. It can be deadly slow loading collada documents upwards of 50 mb.