For you, with warmed caches. The problem is that most users aren't you and so when they follow a link to example.com their client makes that first DNS request for example.com, starts the connection and TLS handshake, etc. and then sees a request for e.g. cdnjs.com and does that same work again for a different hostname. If (in that example) you were hosting your site on CloudFlare you'd have the same work for the first connection but not the second because it'd already have an open connection by the time your HTML told the client it needed your CSS, JS, etc.

Here's an example: check out https://www.webpagetest.org/result/190125_F0_a1a180631ecebd8... and notice how often you see “DNS Lookup” and ”Initial Connection” times which are a significant chunk of the total request time — and ask yourself whether it would be better for the render-blocking resources to have those times be zero. Especially measure how that works on a cellular or flaky WiFi connection, which is closer to what most people experience in the real world.

As to the gigantic bundle of JavaScript, do some real browser testing and ask whether it's better to wait for the entire resource to be loaded before any code runs — and to repeat that entire transfer every time one byte changes — or only block on the portions needed to render the page. Yes, having 8MB of JavaScript is too much in aggregate but the solution is to use less and use it more intelligently, not slap it all into a big ball of mud.