Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load.
[1] https://getbootstrap.com/docs/4.0/components/navs/#javascrip...
In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request.
[1] https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js...
Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.
I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there.
However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.
Or you can do it in CSS actually instantly.
And no, complexity generally doesn't negate this. Earlier this year I built a series of complicated medical forms for a healthcare web site that are all HTML + CSS + < 2K of jsvascript, and they all respond instantly because I did't lean on JS to do everything.
The pages are fast, responsive, work on any device, almost any bandwidth (think oncologists in the basement of a hospital with an iPad on a bad cellular connection), and the clients are thrilled.