It cannot be a member function since the assumption is that you are not the author of Wombat, i.e., you cannot change the class itself.
Why the heck does Nap, for example, need to be a non-member that introduced syntax inconsistencies? It can just as well be a member function!
The point is not to reduce the number of developers, but to separate the core interface from a secondary interface. In fact, doing so allows for a larger development team, since those who develop the secondary interface are insulated from changes to the implementation of the class since they can only use the public interface of the class. This is what Meyers means by increasing encapsulation by preferring non-member non-friends.
Sure, classes grow big and can be hard to maintain. But who's going to maintain those non-member functions? Classes can still be maintained by several people.
Of course the non-members (assuming they are not friends) will not be affected by a change in the data layout since they never access the data directly. If they are affected, then it is because of a bug in a member function, in which case fixing the member function will also fix them.
And if a change makes those 60 member functions go awry, then what's to say those non-members won't be the same? If they do work even with those internal chances, then so too, can the member functions, if designed correctly.
That is a non-solution since you cannot provide a member function to solve every conceivable problem, unless your class is intentionally designed such that it cannot be reused.
And if you stop deriving classes and implement everything into the base class, you won't get the "can't use function X with object Y" that Bjorne describes.