There is no step by step process to do this. There is no convention on how to write plugins so each developer can do whatever they want. I tried a while ago to set these conventions in this thread http://www.question2answer.org/qa/31654/convention-plugin-identifier-naming?show=31654#q31654 but I don't know if people are actually following them. I still am and use the <developer id>_<plugin id>_<table name> (e.g. pupi_pc_mytable) approach. So if you would like to remove one of my plugins you could just drop all tables named after the given plugin id (e.g. pupi_pc*).
For other developer's plugins it will depend on each plugin. However, the Q2A way to create tables is by means of the init_queries() function. So looking for that function is a good starting point. I always use it in my plugins but I noticed there are many plugins around that don't and end up creating tables absolutely anywhere, such as the badges plugin. In those cases probably the best way would be to dive into each file of the plugin and look for a CREATE TABLE statement and get the name from there. Once you have the names for the tables just drop them.
Thinking in terms of how to improve the process at a core level then it is a long way to go, as plugins are not actually installed/uninstalled/disabled from the core: the core just executes its code, whatever it is. The simplest approach I can think of would be for the plugin to have a deinit_queries() function that would perform any clean up. So the core would just need to be modified to allow calling this specific function for a given plugin. This feature should come along with the ability to disable a plugin as after removal the init_queries() function would make the core request for db initialization.
