At the time the minimum RAM requirement for Mac OS X was only 128 MB. WebKit was to be a system component, so it would be active in memory much of the time. Under these circumstances every MB of code counts, so it's easy to see why the leaner codebase of KHTML was found appealing.
However, I think there was also the psychological factor of Mozilla's reputation at the time as an open-source quagmire. The Netscape 4 code they had inherited was deemed unmaintainable, and so Mozilla started over with a rewrite that many thought was too complex and tried to reinvent everything under the sun (e.g. it contained a version of Microsoft's COM). Mozilla turned out fine eventually, but back in 2002 this wasn't quite so obvious.
Not exactly. There's a reason WebKit saw wild adoption by all sorts of projects, while Gecko adoption stagnated. The Mozilla codebase is still too complicated for most people.
Arguably, though, even if Gecko's code base were taken down to be smaller and easier to use than WebKit (and I have no idea how it actually compares today), it would be at a tremendous disadvantage because so many projects have incorporated WebKit.
If I want to use WebKit in a new project today, I can find a ton of people online who have done so in the past and use their experience to get me through it. If I want to use Gecko in a new project, I will have a considerably smaller amount of outside experience to lean on.
However, I think there was also the psychological factor of Mozilla's reputation at the time as an open-source quagmire. The Netscape 4 code they had inherited was deemed unmaintainable, and so Mozilla started over with a rewrite that many thought was too complex and tried to reinvent everything under the sun (e.g. it contained a version of Microsoft's COM). Mozilla turned out fine eventually, but back in 2002 this wasn't quite so obvious.