let me start by stating what should be obvious, but which if i fail to note will result in a lot of unwanted email in my inbox: a KDE port/integration of the Mozilla suite, especially Firefox and gecko, is useful and important. go Zack and Lars!
however, this effort does not reduce the usefulness of khtml (the KDE html rendering suite) to KDE. khtml is a bridge to other projects, a way to stress test the rest of our libraries, is a source of interest for several KDE hackers and is lighter on resources that gecko making it more appropriate as a component for apps that need to show some html but whose primary purpose on this planet is not to be a web browser. but these are not the most important reasons for khtml continuing to exist and be maintained.
the biggest reason is that it provides a component to our internal set of applications and libraries that a modern desktop can not be without, and that it is the completeness of that set of technologies that gives KDE one of it's most valuable assets: agility.
others have said it before me, but it bears repeating: KDE is the only mainstream desktop that is nimble enough to push out broad sweeping changes that require application support to matter in a very short period of time (e.g. <1 year). this is due in large part to the large number of applications that are developed as part of the larger KDE project community. this include applications in KDE extra gear as much as it does those in kdebase.
Microsoft has a large stable of applications, but the internal management structure does not lend itself to nimbly changing the applications across the board. GNOME has the community oriented aspect necessary, but lacks the coherence across application projects to fully assert such changes at will from the center. (i'm noting making this up, Havoc said as much in his recent blog on his ideas for GNOME3.) Apple probably has the internal structure to accomplish this, but not enough applications.
with khtml, KDE can do something interesting and cool in a base library and instantly have it available in every html using KDE application. inline spell checking was one such cool addition in recent years. we couldn't do this without khtml.
as KDE4 comes up we'll be able to make the changes we desire and need in khtml without Mozilla becoming a show stopping blocker for us because their development cycle doesn't match ours. we can make changes to KOffice without having to wait for OOo to decide whether or not to join in and make a new release, which is especially poignant given that KOffice will be using the same file formats as OOo. we can deliver a few hundred native applications in one fell push to the download servers that coherently deliver what our libraries have to offer.
now, this does not mean we should not continue to improve our working relationships to Mozilla or OOo or other such projects, it just means we can do so without becoming inextricably tied to their schedules and priorities. in fact, KDE is probably the most capable desktop to form such working relationships because the liability involved in such cooperation is very low for KDE. this lowered risk affords us greater latitude to explore the options in the wider world, and we should take advantage of that.
viva la khtml!