My thoughts on the proposal of the question is a no go. I would avoid storing CSS in the DB. One reason is already explained by sama55 in a comment and it should be enough.
Regarding Jatin's answer I think it has a several points to discuss, but just a few actually related to the question. I'll go through all of them:
1. Storing JS in the DB (if that is the idea too) is a no go either, IMO
2. Regarding JS/CSS conflics I believe they should be tackled by just following convetions (http://www.question2answer.org/qa/31654/). I don't really know what kind of issues you've faced but following those practices should simplify things.
3. If the conflicting issue is actually JS libraries import (eg, 2 plugins importing jQuery UI, bootstrap, etc) then the issue is much deeper than it seems. I've thought in many alternatives but none is great. The best thing you can do is allow the user to disable ALL those libraries at will. That way, if a plugin previoiusly imported a library then the user can disable the import from your plugin
4. It doesn't exist such a funcion (plugin_exists()) but you can play a bit with modules existance to reflect this behaviour. Take a look at the core.
5. You mentioned overriding methods. If you are talking about an override (http://www.question2answer.org/overrides.php) then you're in deep trouble. Plugins should try to avoid at all means these overrides and I wouldn't recommend publishing such a plugin unless it has a huge WARNING. That can brake many things. If you're talking about layer methods being overriden then again, then there are 2 options. One of them is poorly designed and it overwrites some qa_content key or HTML does not look good when the 2 plugins are active. In the first case, you'll have to fix the plugin yourself or complain to the plugin's author :) In the second case, I will have to tell you that the issue happens "by design". It is impossible to be sure how your plugin will fit in a different Q2A installation with plugins you've never seen. Sadly, the 100% best way to go, IMO, is not a technical answer, because right now, the core is not ready to handle this situation, but rather a disclaimer will get you out of trouble next time :D
Switching to dkd903's answer, I have to say it sounds pretty good but will only be useful for static CSS / JS files that should be included in every request. This considerably limits the benefits of doing so. Consider the following situations:
2. JS usually has a dinamic component. I'm talking about your custom JS code rather than static libraries in this case. It is most likely that you have to perform a PHP echo to send data from PHP to JS. And you cantt minimize that in a static JS file. Even if you remove the echo and perform an AJAX request in order to keep the JS static you'd still be performing an additional HTTP request which was exactly what you wanted to avoid in the first place.
3. There is an additional situation to handle which is user related. How and when will you be compressing the files? On each PHP request is, clearly, a no go. Best approach woud be to let the user manually fire the event and, probably, after each plugin saves their data. The latter one is easy to understand why. The former one is justified because a user might change a CSS plugin file directly from the static file that is supposed to be compressed and then expect a change in the application. Then the user will know that they have to click a "Minify" button to do so. Also, plugins will have to register their static CSS and JS file with the core in order for this to be possible. Of course, this would require core changes. And don't forget about plugin uninstallation...
My conclusion: These proposals result in little benefit for too much effort for core developers, plugin developers and even the user. I do agree, however, that there must be a way to improve static CSS/JS imports. I just can't figure it out now :(