With respect, I think this article is largely misguided and seems to come from a general rant-perspective rather than from any coherent reflection of the state of things today.
Apart from the contradictory things it says (e.g. "Don't use a CDN" then "Use caching!" and "Don't load everything at once - use links" then "Don't make user redownload everything if they click a linkl"), there are some ideas that need challenging.
Also the general tone of this article is pretty poor (calling people "fools", "idiots" etc) - please treat each other with respect!
Single-Page Apps & JSON
Modern frameworks support lazy-loading. The entire thing is not loaded at once. Small individual HTTP requests are sent on-demand to request the required parts of the site as they are needed.
Sending a single JSON response to the browser via a fetch() will many times be significantly smaller & faster in terms of payload/bandwidth than doing an entire page reload since you do not need to reload the HTML, the CSS, the images, the favicon, the scripts etc then re-layout and re-render the entire thing when you could have just got a 500 byte JSON payload back and updated the existing page in real-time. Often it is an API you are working with - pretty much everything I have worked on in the past 5-10 years has had just normal API endpoints as "the backend" and your web frontend talks to those endpoints in the same way as any other API client would.
There are also alternatives to JSON that are easily usable and higher performance (in terms of parsing and payload size), e.g. gRPC.
Server Side form validation
I think it is generally agreed that real-time validation of input fields is a net-win for users - HTML5 allows for basic validation to happen "natively" in the browser anyway, but lightweight javascript validation is going to run in The alternative of leaving the entire thing to be validated on the server after submit might work for small forms with perhaps 3 or 4 fields, but the user experience for a larger form (e.g. tax return etc) that takes a long time to fill in will benefit hugely from real-time validation as the user is entering data. There are also a11y (i.e. screen readers etc) problems of just doing a page reload, rather than something dynamic.
Javascript will not stop tab from working in a form, unless you go out of your way as a developer to do so. I am not aware of any common frameworks in use today (React, Angular etc) that break taborder.
Google Analytics/Server-side data
The days of your site running on a single server are long, long, long gone. You no longer have a single apache log you can parse to get realistic usage information. While I do not question that Google Analytics et al are potentially dubious, some sort of client-side data collection framework is a logical approach when running a highly-distributed app across many physical servers, particularly if you are using XaaS solutions such as AppEngine etc where you don't get any server logs to process.
Anti-framework rhetoric
I think being anti-framework is unhelpful. Using frameworks is not a "click a shiny button and everything is done for you" (as hinted at elsewhere on this person's site) - for things like react and angular, they provide a framework for writing modular, well-encapsulated software that works efficiently.
Without frameworks and everyone doing things their own way, you'll end up with longer development cycles leading to lower-quality software riddled with subtle bugs (e.g. my own personal war-story was a favicon getting cached that introduced a subtle user-session bug that allowed people to view other user's data - this was from way way waaaay before React, Angular and even RoR was on the scene, and we were using a home-made solution). You don't get these kind of bugs so much now because the framework is written once by smart people and then exercised and tested much much more than any homemade approach ever could be, just due to sheer numbers. Bugs will be found and fixed before your own project even started.
Programming languages being slow
Python is not fast I agree (and I have minimal direct experience of Ruby), but in the realm of web dev, any server side calculation is going to be waaaaay faster than the network RTT likely by many orders of magnitude. Add in to that slow database queries, and the choice of backend language is kinda meaningless. I would not expect the average backend web application to be doing any hard-core calculations that would benefit from a lower-level language - most are just acting as a facade or adaptor to other backend services or some slow & bloated database.
tl;dr summary
I think that there is a perception among various people who scoff at web development as this trivial thing and that front end engineers aren't needed, and that they only exist to add javascript complexity that does nothing and that 100% of a websites functionality can be handled with plain HTML + HTTP Forms.
The reality (IMO) is that the browser is the "new OS" and that for most consumer & business software, running in the browser is the obvious choice. Like it or loathe it, this appears to be the current approach.
Sure we could go back to something akin to early 1980s or 1990s user interfaces (and indeed some of the web-based software I use regularly at work uses some of those "engineer designed" plain HTML + forms approaches and they are fine), but we have to think about the usability and accessibility (plain HTML does not guarantee that a website is accessible - it might meet the letter of the law, but in spirit it can be sorely lacking) of our user interfaces for all of the people who use our software now (be they young or old, technically savvy or barely used a computer before): many will consider a raw Times New Roman HTML page as jarring and technically "scary", and those that rely on accessibility tech will suffer greatly.