Yep - WebbotLib has a large footprint - and I make no apologies/excuses for that.
It uses 'late binding' - ie at compile time we just know there are a collection of resources and at runtime we work out how to use them. Others like AVRlib take the opposite approach and assume certain sensors work using certain timers/resources etc. They produce much smaller code as a result. BUT BUT BUT this means you can support MUCH less devices. ie AVRlib only uses timer 0,1,2 (as they are present on most AVRs) - so for an Axon then timers 3,4,5 are almost never used.
Its a bit like C++ in that there is a hit for each new 'class' (ie kinda code) you use but not much impact for each instance. eg add your first 'Sharp GP120' sensors bumps your code size - but for a second, third...etc it doesn't make much difference.
AVRlib tends to only talk about timer 0,1,2 and so any code that requires a 16 bit timer means you CANNOT use anything else needing a 16 bit timer as Timer 1 is the only answer. Small code but restrictive. WebbotLib removes this restriction - but, admittedly, at a price.
But then if we all knew how to program then we would all be writing in assembly language and wouldn't need any libs at all!!!
And thats how I would (and do) do it for a given processor and project. But WebbotLib is aimed at different processors being used in different ways. ie flexible.
ATMEL have already dropped the ATmega8 (8k) and your ATMega168 (16k) is also on the verge: if not already dropped.
The plug in replacement ATMega328P (32k) costs about the same and gives double the program space. The ATMega8 and 168 are effectively dead.
So I'm not going to 'fix stuff' as there is 'nothing to fix' - just pay the few dollars to upgrade to a 328
[Edit] I will continue supporting the ATMega168 because, as you said, you have already got it to do a number of things before space became an issue.