That's all great for the specific points raised, but maybe there's a
more generalized, "philosophical" response to be made, to cover the
title question.
(I've been lurking and studying for a few months, but those who've
been around longer feel free to say all the following is completely
backwards *grin*)
Habari has a more-than-usually minimal concept of what's "core"
functionality, with the expectation that if you want something more,
you'll either install the necessary plugin, or add it yourself(eg.
content types are extensible, so no point in having a bunch of default
fields that may not be used.) So, Habari /itself/ does roughly the
least possible(title, entry body), but makes it easy to bolt on just
about anything else you want. As I see it, this puts it a bit closer
to Drupal than WordPress, at least from an architectural standpoint.
Most applications take the approach of trying to cover all or most of
the fairly-common situations(categories! tags! trackback? ecommerce?!)
right from the start, with plugins only becoming necessary for
less-common tasks. So, for example, a few versions back WordPress
added a gallery creation feature in the core, but podcasting still
probably calls for a plugin.
This has certain advantages sometimes, but it also means that if you
/don't/ want those features, you have to take the time to hide them,
if the application even allows for it.
I don't think either approach is inherently superior, but it /is/
necessary to understand which one applies to whatever application
you're looking at, in order to know what your options and expectations
are when a feature is "missing." I've seen people in the MT forums ask
about incredibly specific functionality seemingly without even
considering to look in the plugin directory.
Beyond any of that there is, of course, the basic fact that Habari's
still only around 0.6.