If you look at the source for module_enable() you can see what is going on. In particular, several cache tables get cleared, as does the registry. It also does filesystem scanning to rebuild module data. All of these are expensive operations.
If you look at the source for system_modules() (this is the callback for the modules page), you will see that system_rebuild_module_data() is called. This is also an expensive operation.
My guess is that something on your server isn't optimized. Even though you have gobs of CPU and RAM, Apache and MySQL may need tuning. I have seen similar instances to yours, where MySQL hangs due to heavy loads and then incoming HTTP requests stack up. Eventually, connections to the database will block, and slow things down more. When this happens, the system will very often hit swap due to the number of httpd processes. A live webserver hitting swap is a catastrophe; load/memory will swell exponentially.
In this case, you need do a few things.
First, run mysqltuner on your database, and make sure buffer sizes are OK, and that your max memory usage is sane.
Then, tune Apache to make sure you won't ever hit swap under normal conditions by limiting the number of concurrent servers. Enabling keepalives, and setting up some aggressive HTTP cache rules can also help reduce the number of active httpd processes. Using the CDN module can also help reduce Apache load by offloading most CSS, JS, and image requests to the CDN instead of your server.
It is also possible that your memcache doesn't have enough memory, and you are thrashing. You may need to check these settings, and also check which tables you are offloading.
I would also avoid enabling/disabling modules outside of maintenance mode. Schedule windows where you can do work. Assuming you stage/test everything properly, and work from a checklist, you shouldn't have more than 5-10 min downtime to do this.