It's oft just a matter of what you usually work with. When I do that type of data processing client side JavaScript is an enhancement to already working pages, because I'm an accessibility consultant. Aka where scripting only solutions are broken inaccessible trash no matter how many TypeScript using React fanboy clown-shoes claim otherwise.

If I "have" to use client side scripting for "boring things" like searching and manipulating data, I automatically assume I'm doing something wrong. That could possibly land my clients in court.

Thus the only place I really see for client-side scripting libraries is for stuff that should be scripting only. Like motor control interfaces, medical device panels, musical instrument controls (like the Garritan software for my EWI-USB) and of course calculators. All of which are either state machines, or "views" for state machines.

And if I really "had" to use client-side scripting for that type of data, libraries and frameworks go to the bottom of my list because I can probably do it cleaner, faster, and simpler as vanilla code. Often by storing the client-side data on the DOM and manipulating it there.

But yeah, we don't all work on the same things, the same way, with the same requirements. Perspective is important.

From a certain point of view...