That is sneaky, is there any advantage in doing this or is it just masking resource usage ?
Well, it has its pros and cons.
The advantage is that it makes the filesystem scanner (that needs to run in kernel-mode anyway) slightly faster (avoiding the need of transitions between kernel- and user- mode).
The disadvatange is that any error in the engine usually means instant computer crash (or instant reboot).
Also, porting most stuff to kernel-mode is quite hard - so e.g. unpacking support is harder to implement in this case (especially if you want/need to use 3rd party code). That's one of the reasons you cannot enable archive unpacking in AVG's on-access scanner, by the way...

Also, it's worth noting that this model had been used by Norton and McAfee (roughly till their 2004 versions). It was abandoned then - I suppose they figured out that the drawbacks simply outweighted the benefits.
How can we measure such resources usage in this situation (kernel-mode driver)?
There's no easy way because the driver memory is allocated from a system-wide pool (i.e. it doesn't belong to any process, really).
A simple way to get a rough idea is:
- boot the machine with the driver active
- in the Task Manager, go to the Performance tab and note the values in the Kernel Memory section (Total, Paged and NonPaged values)
- uninstall the driver (or the software which carries the driver)
- reboot
- again, use the Task Manager to find out the Kernel memory usage
The difference should quite accurately indicate how much memory the driver allocated.
A slighly more sophisticated method of resource tracking is to use the Windows Driver Verifier (verifier.exe). This is a handy tool (ships with Win2K+), but it's not really designed for normal users (just for developers/geeks). The tool allows you to track all memory blocks allocated by a driver, and much more.
and i guess, "error in user mode = program crash only" but error in kernel mode = blue screen".. right?
Undoubtly...

And this includes e.g. cases of (slightly) faulty RAMs - the larger the "crash surface", the bigger the chance that the computer will keep crashing on the user. Even MS is slowly realizing that their goal for the future should be to minimize the amount of code running in the kernel - as is evident from the early specs/builds of Windows 7 (the successor of Vista/Win2K8Srv).
Cheers
Vlk