As @bmike said, Internet Sharing hides a lot of complexity behind a very simple interface, and some of your questions can't be answered authoritatively without interviewing some of the Apple engineers behind it. But that won't stop me from taking a stab at it...
1) AirPort is different from the other interface types because in order to share over AirPort, your Mac has to actually create the wireless network (as opposed to just providing service over an existing ethernet, FireWire, etc connection). This means that InternetSharing needs to have a bunch of info about how to create the wireless network: network name (SSID), channel, security, etc.
2) Resharing over the same ethernet interface is useful under some circumstances. For example, on my home network my ISP provides limited number of static IP addresses for my use. I run a Mac doing the equivalent of Internet Sharing (actually, I set up the daemons manually as @Spiff recommended) to reshare over the same ethernet. Result: if I put a computer on my home ethernet and config it via DHCP, I get a private (behind-the-firewall) IP address from my virtually unlimited internal pool. If I manually config the computer with one of the public IPs, I get full unfitered internet access, but use up one of my limited public IP pool. Because they're both on the same network, "moving" a computer behind or in front of the firewall is just a simple configuration switch.
On the other hand, if you did this same trick on an ethernet network that already had a DHCP server, computers attaching to the network would randomly get configuration from one server or the other, leading to unpredictability, confusion, and hair-pulling. It's definitely a use-only-if-you-know-what-you're-doing feature. Fortunately, Internet Sharing is smart: if it detects another DHCP server on "its" private network, it shuts itself off to avoid trouble.
3) I don't know of a way to change the private IP range on an IS-created wireless network. On the other hand, it shouldn't really matter, since the network is being created by Internet Sharing, and therefore it doesn't have to worry about conflicts with any existing network numbering.
4) You can add interfaces with Apple's USB Ethernet Adapter. Get some USB hubs, and pile them on!
This is indeed quite broken in Mountain Lion. Once you've fixed up the default route as you describe in the question, you're still left with the problem that Mountain Lion is giving its bridge interface address to clients as both the router address (which is correct) and as the DNS server address (which isn't).
Verify that this is the problem by entering an HTTP server IP address into the address bar on a client web browser when connected through your Mac after you fix default routes, and it should load up fine.
My solution to this problem is to fix up the route as you describe -- which could be automated, of course -- and to keep BIND (aka /usr/sbin/named) running in the background on my Mac in a forward-only configuration, forwarding all queries to Google's public DNS servers. This doesn't fix the underlying brokenness in Mountain Lion, but it makes things start working for the clients.
A couple useful resources:
http://www.macshadows.com/kb/index.php?title=How_To:_Enable_BIND_-_Mac_OS_X%27s_Built-in_DNS_Server (how to fire up BIND on OS X)
http://gleamynode.net/articles/2267/ (how to configure BIND for forward-only operation -- of course you will not want to make BIND only listen on 127.0.0.1)
It would be far preferable for Apple to make this feature of their OS work as advertised, but in the meantime I've found this is a viable workaround.
Best Answer
This could possibly get you part of the way on your journey to the final solution, though it hasn't worked for me so far on mountain lion. I'd very much like to know what your solution is if you find one!