And I'm not the kind of person who follows the standard just because "Hey, that's the standard bro!".
There is no standard on how to structure libraries...
As long as it makes things easier or makes sense to me, I tend to bend/change things to my advantage.
This is the problem. It makes sense to
you. Don't forget that SFML is a library that many people use. Instead of arguing in favour of this suggestion by stating that it would benefit you, try to convince us that it will benefit a lot of other users as well. Also, just because it makes sense to you
now, does not mean it will make sense to you in the future. Requirements change, bad habits stick around for much longer.
Most of the developers don't even bother with the Sound, Network and sometimes Graphics modules.
What is your source? I normally don't ask people this question, however given that that statement is the main point of your argument, it would be nice if we could verify if it is indeed a fact or just an argumentum ad populum. If you are referring to developers in general, and not just those who use SFML, then it
could be true. However, if you are referring to those who already chose to use SFML, then I can tell you that what you said is far from the truth.
Which is why I prefer GLFW over SFML (does what it promises and nothing more).
I don't know if you are aware of this... but you can use sfml-window on its own. And judging by the APIs of GLFW and sfml-window, they are very similar. I don't know what you are referring to when you imply that sfml-window does more than it promises.
Feel free to try making your own project (for your IDE) that includes the needed modules and as long as you have the proper files included and define the proper macros then you're good to go.
You need to define
one thing, SFML_STATIC if you are linking statically. And you need to include only the
necessary headers for your own project, in your code. I don't know why you think that what you are doing is advantageous in any way...
My project made a static library and for some reason the overall size of my executable was smaller 
(way more smaller)
Of course it's smaller. If you understand what the compiler and linker does, then you would know that it can optimize a lot more if you compile everything into a single library.
However: if you do this, you will
potentially reduce the optimization opportunities when building your own project, and your own project
might end up larger when linking against your monolithic library then if linking against the modules that you really make use of. This depends heavily on how you use the library of course, and without providing this library of yours for us to examine or showing us the code that you used to test your executable size, we won't be able to check if this is just an obvious case of a very generous optimization scenario.
I still don't really understand how these discussions about monolithic libraries can last for so long... If you ask me, the people who favour monolithic libraries over modular libraries
solely for convenience (i.e. less typing/clicking) reasons don't know how to work efficiently. If you spend
so much more time configuring your project than actually... you know... writing code, you are clearly doing something wrong. Disregarding the fact that I have a bit of experience, it takes me
seconds to add the extra dependencies that I need to my linker settings. If you compare this to the
hundreds of hours I spend writing code you can see why this makes absolutely no difference. In fact, the time we spend writing these posts alone is enough to last at least 100 projects worth of dependencies.
