> My point is that if you say thing like "significantly/several times
> higher memory footprint than X" you are basically scaring the users
> away from the module.

Only those users who know they'll be processing significantly large
documents.
I don't think "scaring away people" is a good enough reason *not* to
document performance characteristics. For example, we already mention
that string joining is faster than repeated concatenation; I haven't
heard anyone complain that it scared people away from string
concatenation. And while it's true that we shouldn't try to document
performance characteristics *too precisely*, it is still a good thing to
document the most outstanding facts (for examples, C accelerator modules
are clearly superior in performance to pure Python modules; should we
shy away from documenting that, and instead present it as some kind of
neutral choice?).

And, of course, if minidom gets some serious performance attention, the
claims will have to be revisited. But given the amount of attention
minidom gets at all, it sounds rather implausible.

> If for an average documents it takes, say, 30-50MB of memory, it seems
> perfectly reasonable to me, even if ElementTree takes 3-5MB.  I would
> actually consider 100-200MB still ok too

Some use cases would not really like a 100-200MB memory consumption, or
even 50MB. Think a long-running daemon, for instance.