Largely because it gives us much more control over how and when the CSS is loaded. It allows us to:
1) Download all the CSS (and JS) in one request which reduces the number of round trips and resource blocking
2) It makes it easier to push the CSS into local storage which is dedicated space for the domain (we don't have to compete with resources on other sites for space in the web cache) and tends to stick around longer, so we don't have to download the resources on repeat visits as often
3) It allows us to load only parts of the combined CSS on other pages. If you include CSS files A, B, & C on the first page and only C & D on the second page the user visits we can download all three files A, B, & C in one request on the first page and then only download D on the second and still only apply C & D on the second page. It provides a lot of the benefits of splitting up your CSS into multiple files without adding the overhead of multiple downloads.

I don't think we have enough data either way for sure to say definitively about the reflows / repaints. I hope we can have a better answer soon.

In some extreme cases we have seen a small decline in perceived performance using this technique. Basically if there isn't much CSS and it's already in one file the overhead of the Javascript and hiding / showing the body actually made things slightly worse. We have other optimizations to use in these cases that include the CSS as a standard link tag to a minified CSS file on a CDN, but most of our clients aren't in this edge case. Generally we've seen an improvement in render time and perceived performance still, especially w/ sites that mix CSS and javascript in the head.

1. We use some internal stuff and a little bit from http://csstidy.sourceforge.net/
2. I don't have as much data on this as I'd like in order to say definitely yes, but my initial testing has shown it to improve. Hoping to look at this more soon.
3. No, it doesn't yet, but we are planning to add this soon.
4. The javascript fetch is added in the head of the document and then the STYLE elements are added in the dom wherever the original CSS link tag or style tag would've been in the original document.
5. We set the visibility of the body to hidden until the CSS is applied to the document in order to prevent FOUC. I didn't mention this in the post, so thanks for bringing it up.

These are actually the first views. We're including the js and css as inline js in the page request, applying the js and css to the page, pushing it into local storage, and updating a cookie to indicate to the server which files are in local storage on the client. This way on subsequent pageviews we can know what resources to include based on the cookie. This leads to a much larger initial page request, but fewer HTTP requests overall which is where a lot of the performance gains come from.

I don't have any stats on the localStorage size vs cache sizes handy, but we'll probably address those in a future post when we have some more data on how these optimizations are performing in the wild.

It's a little "homebrew" and requires a Twilio account for the text messages at the moment. If there's more interest I might consider packaging it up a little cleaner and/or making a simple service out of it.