This is a suggestion regarding the content model as it pertains to the style and link elements. I suggest that they be permitted wherever phrasing content is expected, similar to the script element, in order to apply to the document (or, in the "scoped" case, to the siblings) retroactively. Most browsers support this already, and I believe it would be very useful for developers of high-performance web applications.
I'm a former Facebook engineer, and during my time at Facebook we put a lot of emphasis on fast apparent load times. In order to accomplish this, we would inject most of our script tags at the end of the body element rather than in the head element. That way, the static content of the page could be made visible quickly, before kilobytes or megabytes of JavaScript had to be downloaded.
With the advent of CSS3, animation and even some interactivity can be implemented outside of JavaScript, but the CSS syntax can be quite verbose, especially when many of the experimental features need to be included multiple times with various browser-specific prefixes. This would suggest that, for large style sheets that mainly define animations or other non-static styling rules, developers could benefit from including the style or link elements at the end of the document instead of in the head, to be applied only after the static content is visible. Currently, HTML5 semantic rules do not allow for this, though major browsers all currently permit it. Relaxing the restriction on where style and link elements can appear could solve this problem.
An alternative:
If you find the notion of ad hoc style and link tags peppering HTML5 documents offensive, perhaps it would be preferable for HTML5 to permit an optional "foot" element to appear after the body element within a document. The foot element would expect metadata content just like the head element, allowing for CSS and JavaScript to be loaded after the body content is already visible.
While browsers do not currently recognize a foot element, most already treat unrecognized tags as transparent elements, and they already treat elements after the body tag as children of the body, so metadata content included within a foot tag will already be handled properly.