One problem which I wanted to avoid in Epicyon [1] is what I call *the ecosystem of badness*. With other web apps - like Wordpress for example - you can also have themes which can be made independently. But if themes can include arbitrary CSS and Javascript then this means it's possible to create themes which exfiltrate data or attack users, and a black market [2] then develops around such themes, which is comparable to the market for zero day exploits and other *"cyberweapons"*. In the presence of such threats, projects then usually create an official store or approved site for downloading themes, and once again you start to get gatekeeping and centralization. Points of control.
So to avoid that whenever a theme with custom CSS is activated in Epicyon it first has to go through a santization step, which removes or blocks javascript, nested style sheets with off-site links and other common malware vectors. This might limit the range of creativity to some extent, but I think the tradeoff is worth it. A lot of subsequent pain and drama can be avoided if you but some thought into the initial design, given the long history of how web apps have previously been weaponized.
Using one main set of CSS files which are then modified for each theme by changing the variables is also a strategy to avoid *the ecosystem of badness*. It also helps to keep maintenance to a minimum, since it avoids needing to maintain a separate set of CSS files for every theme.
Of course, since this is Free Software it's possible to easily remove the sanitization step from the code. But doing that probably means needing to fork the codebase, and this then makes bad actors easier to expose. For instance, you might see a fork with a single commit removing a few lines, and you'll then know that sites using that repo might be up to no good.