> My company does complex cloud and on-prem web-based apps, JS front and back.
Then you've certainly run into power users.
Chances are browsers can load and display a 2MB server-generated HTML table faster than the DI system in your 5 MB angular app can start all the required services to be ready to launch your pagination component.
However once it is ready it may be quickly apparent that users would be much more productive using that giant table and CTRL+F than a laggy angular app that would struggle even handling that much data at once in an idiomatic way.
Of course I am making this up to illustrate a point. However I use "one giant HTML table" as a sort of bar to meet when developing in modern frameworks. If with this insanely complicated and large array of tools I can't even do better than that (faster to implement!) competing solution, I might as well not bother.
That "a bunch of large server-rendered HTML tables" just so often happen to be the previous solution that was in place, and power users are likely to complain if we do worse, is just the cherry on top.
To do better we often have to avoid certain things that would be considered modern. Like not putting lots of empty space in our layout, no server-side search that would introduce too much (pointless) latency compared to client-side, and some un-idiomatic stuff to actually handle large[1] amounts of data without change-detection/updating in our framework of choice eating user's CPUs for breakfast.
[1]: The amount of data/elements at which change detection in idiomatic Rust and Angular becomes slow wouldn't have been considered 'large' 15 years ago. Though obviously people then had to put thought into this stuff and it certainly wasn't automatic.