If it was meant to be a feature, it should have at least been documented. How is it good to have undocumented, arbitrary limitations on a platform that you are using?
using inline style tags directly after elements can have a noticeable speedup on a pages rendering, dynamically generated pages could quite easily have well over 30 with the only downside being this silly limit.
and that isnt mentioning the boundary situations for things like web page builders with the ability to user define styles in which having a "lot" of style tags is architecturally a good idea.
I am quite tired of this "your doing it wrong" meme when its used instead of "you arent doing the same thing I am doing"
It makes perfect sense if you're generating your HTML and CSS from some kind of code-generator. Limiting it to only 30 style tags is really arbitrary and small.
The one time I've run into this 'bug' in the past was on a site that used lots of javascript plugins, more and more of which are coming with their own CSS files nowadays.
Of course you can concat them together, but that adds a maintenance burden in the future whose size can vary wildly.
At the very least, there is a documentation bug here. The reason for this seemingly arbitrary limit should be documented by MS.
More seriously, I was once treated VERY skeptically by an old-school programmer (not at MS, never worked there) when I replaced some of his fixed-sized buffers with resizeable ones. "If our customers are running workloads that create more than 256 frooble node objects, I want to hear about it." Via a bug report? Really? And then get a new bug report next year when the new limit is reached? But he was adamant, and if it was up to him we wouldn't have made the change at all. The way he worked, you knew how many frooble node objects the customer needed, and if you were wrong then you fixed the code.
Every stylesheet is an extra (blocking) HTTP request. 5 is already too many, but 30 is seriously impacting your user's experience.