catch and I discussed the merits of the .js class being set on the <html> tag by core/drupal (drupal.js).

WimLeers: grep for ".js " in all CSS files. Actually quite a lot of things are using this. Notably: dropbutton.
WimLeers: Actually, 90% is dropbutton, 10% is legacy leftovers
WimLeers: catch: dropbutton is a complex beast. I can only hope the reasoning for this .js selector stuff is doc'd.
catch: WimLeers: this pushes me towards footer for both.
catch: 'cos I don't think either of these have a good reason to be in the header.
catch: and removal of "js" class on <html>?
catch: And they'll encourage bad behaviour.
WimLeers: Hrm, but Jesse sometimes prefers overly specific selectors to be safe. I'll ping her to see if she remembers.

So I pinged Jesse Beach, who helped finalize the dropbutton in its current implementation, to ask about its reliance on the .js class in its selectors. Turns out there's likely no good reason for its reliance on the .js class, it's probably only there due to its Views legacy: https://twitter.com/wimleers/status/558614234851196928

document.documentElement.className += ' js'; only has to be in the head if a theme uses the js class, any idea if a lot of themes are doing it?

Well, any Drupal 8 theme that relies on this will be broken for anonymous users anyway then, since no JS is loaded for anonymous users by default. Themes could opt in to this by having their main global styling asset library declare a dependency on core/drupal.
In other words: I think this is a non-issue :)

#10: why does that need to be documented additionally? Anybody looking at the output sees this, and if you look at the corresponding library definition in core.libraries.yml, it's also clear. I don't see what we gain by also commenting on \Drupal\Core\Render\Element\Html? Feel free to propose a patch though, but it feels like that belongs in #2409083: Remove html5shiv from being loaded, it's definitely off-topic in this issue.

I think we should get rid of the .js CSS class, core should not be triggering CSSOM & layout invalidation on every page load by default. If we currently depend on this for something, let me know because I'm sure we can find a better way to deal with it.

For themes that for some reason need that class, they can add it themselves, it's a trivial thing to do.

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)