removing kexts and fixing permissions

You can just remove it manually. No need to fix permissions. You can do it from the terminal, for example,

sudo rm /System/Library/Extensions/foo.kext

where sudo will prompt for your admin password and of course "foo" here would be replaced with the kext you want to remove. Note there are no spaces in that pathname ("/System/Library/Extensions/foo.kext").

You should reboot immediately after removing the kext. You may notice a longer time to log out and to log in after that. The longer log in is due to the system rebuilding the kext cache. Succeeding logins should resume to your normal speed.

As long as you documented which kexts were added, and you know no other tool uses them, sure, doing what you suggest is good. If you have any doubt as to what uses them, it is better for the controller software developer to tell you what software to uninstall. Kexts are generally not to be tampered with unless you are a developer, and know no other tool uses them. If you install anything new after the kexts, be sure it doesn't install its own version of the kext over the one you added.

You don't need to fix prermissions when removing a kext because you are not changing permissions on anything. Deleting a kext within /System/Library/Extensions isn't going to change the permissions of the other kexts in there nor the directory containing them. You of course need admin prevleges to fiddle in there, hense the sudo on that command I showed.

It doesn't hurt to repair permissions other than waste some time. Repair does indeed look at receipts to get its data but it will always show some stuff it's "unhappy" with. It's generally the same stuff no matter how many times you run repair so just ignore it. Personally I rarely do a repair permissions. I don't even recall the last time I did it.

Airport is not the only thing that is in the system that uses kexts. Input devices use them, including keyboards, mice, trackpads, data ports use them including Bluetooth, Firewire, USB, and anything that transmits info in that manner does. There are a number of built-kexts which the normal user is not going to touch, and Apple protects the normal user from doing so by setting permissions to be restricted. It also prevents the viruses from attaching themselves to something that is system linking to hardware. Mac OS developer forums are probably more able to give you a concise response, but that's the general response.

I haven't encountered it for some time now (maybe years), but I do recall installing some end user packages which screwed up some system permissions forcing me to do a repair. Also, I suppose if I were doing a major version or combo update to OSX I might do a repair before and after the update (but personally I don't have to worry about that). Apple is no bargin eitther in always getting the permissions right after some of their installers run. Ok, so I don't really trust apple either!

Ok, good luck with Lion.