1. "using JavaScript, you can identify the scrollbar width [...] so an attacker can identify the underlying operating system"
Using JavaScript, you can simply ask Tor Browser what platform it's on using navigator.userAgent, and it will tell you the truth because lying breaks e.g. websites' custom key combinations. Tor Browser will however attempt to anonymize the platform in passive indicators, i.e. HTTP User-Agent: https://blog.torproject.org/new-release-tor-browser-801 (search for "User Agent")
"Checking every network connection against every possible Tor node takes time. This is fine if you have a slow network or low traffic volume, but it doesn't scale well for high-volume networks."
If you can muck around in TLS cert fields in real time, you can look up an IP address in a hash table...
"Second, the list of nodes changes often. This creates a race condition, where there may be a new Tor node that is seen by Tor users but isn't in your block list yet."
Oh no! (clutches pearls)
Not to say that it isn't worthwhile to tidy up the TLS fields some more, but hyping this as a zeroday is absurd.
Also, it seems to me that whatever they do to make the TLS handshake and certificate look more like a typical web server, they would never be able to make it exactly match. Tor connections could still be identified by simple things like the self-signed certificate, the random hostname, the hostname<->IP mismatch, and so on.
Trying to fix this would be a never-ending losing battle, I can understand why the Tor project aren't that interested in changing things.
Wrt #1, I think the issue is that scrollbar size makes it easier to tell one Tor user apart from another in the Tor browser, not that you can determine they are running in the Tor browser (or even know their platform from a common fixed set). For most users of Tor and the Tor browser, simply checking that they are coming from a publicly known list of exit node IPs is enough (or if they are already hitting an onion service, then it's obvious).
I'd definetely consider Tor Node Fingerprinting (2nd issue) to be an important issue.
Nonetheless, both issues have been _accepted_ as those by Tor Maintainers, yet they failed to act appropriately.
1. "using JavaScript, you can identify the scrollbar width [...] so an attacker can identify the underlying operating system"
Using JavaScript, you can simply ask Tor Browser what platform it's on using navigator.userAgent, and it will tell you the truth because lying breaks e.g. websites' custom key combinations. Tor Browser will however attempt to anonymize the platform in passive indicators, i.e. HTTP User-Agent: https://blog.torproject.org/new-release-tor-browser-801 (search for "User Agent")
(EDIT) This was too dismissive, because scrollbar width differences are more fine-grained than platform differences: https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c5
2. Blocking entry node connections:
"Checking every network connection against every possible Tor node takes time. This is fine if you have a slow network or low traffic volume, but it doesn't scale well for high-volume networks."
If you can muck around in TLS cert fields in real time, you can look up an IP address in a hash table...
"Second, the list of nodes changes often. This creates a race condition, where there may be a new Tor node that is seen by Tor users but isn't in your block list yet."
Oh no! (clutches pearls)
Not to say that it isn't worthwhile to tidy up the TLS fields some more, but hyping this as a zeroday is absurd.