First off, let's talk about what Storm is supposed to be. From their front page we get:
Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation. Storm is simple, can be used with any programming language, is used by many companies, and is a lot of fun to use!
And from their wiki we also get:
Unfortunately, these data processing technologies are not realtime systems, nor are they meant to be. There's no hack that will turn Hadoop into a realtime system; realtime data processing has a fundamentally different set of requirements than batch processing.
However, realtime data processing at massive scale is becoming more and more of a requirement for businesses. The lack of a "Hadoop of realtime" has become the biggest hole in the data processing ecosystem.
Storm fills that hole.
With the "money quote" being this part:
Storm provides a set of general primitives for doing realtime computation. Storm is simple...
So Storm started out as something that was intended to be small, crazy-fast1, and simple.
And while I haven't pulled the jar file to see its actual size, my expectation based upon the description of the project is that the "fat jar file" is reasonably small. If it isn't, then I think the project has missed one of its original goals.
The fact that they are attempting to create a set of primitives for this type of calculation also implies that they are trying to keep things concise. Or said another way, they are trying to avoid bloat and are focusing on providing just a core set of features.
We also need to consider simplicity being one of the primary goals of the project. Really Good Simplicity (tm) extends beyond the API calls and into the package itself. Not having a lot of configuration options makes it easier and simpler to deploy the project.
When you roll those three elements together, I think the converse of your question is an appropriate answer. Why would you want the additional configuration ability that you're describing? It will complicate deployment (therefore less simple), encourages moving away from a tight feature set, and you're potentially worrying about a trivial file size anyway.
And that's your architectural answer. It wasn't done because it was never intended to be supported that way. Architecture and design involves cutting off pathways so the shape can be formed or defined. While I certainly didn't design the Storm package, I can see where their architects may have rejected what you're asking about in order to achieve the other goals of the project.
1 Okay fine, real time systems are better defined as systems that will guarantee a response within a fixed period of time.