I agree with @R.D. The only advantage I see here is allowing other devs to use just specific parts of the library. However this isn't really a necessity either. The size of Slick is incredibly minimal compared to other libraries. Organisation of components is not a priority on my list
Slick should still be modularized for the reasons I gave earlier. Especially for the sake of slick-util.jar, which IMO is going to be the future of Slick now that LibGDX supports HTML 5 rendering.
I'm starting to agree that multiple projects might be the best way. It may introduce more "clutter" in the sense of a fragmented folder structure, but it would also clearly separate sources. And if users wanted to pull slick-shader (for example, a LWJGL user) then they don't need to pull all of the other junk with it.
Of course, this means that things like slick-gui and slick-particle would not be very useful to the straight LWJGL developer, as they would also need to depend on slick-core. These packages would be more useful for removing clutter for those depending more heavily on Slick.
In the end, I feel that our priority at the moment should lie in fixing bugs and RFEs that have been gathering dust in the BUG/RFE forum, and improving features of Slick that are severely lacking. I would like to "re-introduce" Slick as a modularized set of utilities to the LWJGL community, as it would be useful for many of them, but we shouldn't do such a thing until Slick is a bit more stable, optimized, feature-complete, etc.