I know another government contractor whose idea of client responsiveness is to download the entire server database to the client browser on initial load
"Hard discount" stores like Aldi are supposed to have <1500 SKUs, for example.
Now the user will immediately get to see the full item and will be able to page through the results much more quickly.
I've definitely had cases where I had to process the data before sending it to the client, but I've also sent absurd amounts of data and rendered it client side. In fact, I think sending data embedded in HTML to the client is rarely a good idea, and once you've adopted that mindset, apps can look very different.
I worked on an application a number of years ago where it was trying to load all the comments and details about an internal bug tracker into memory. It must have worked fine at first, but after time it was a POS.
If the database fits onto client hard drive and the modifications are rare, preloading everything is almost always better.
If you have a dynamically changing system such as bug tracker, it is still possible to go fully local, but that would require considerable cooperation from server side. When the back-end does not have a fast, efficient API for sending diffs, you may get stuck waiting for it to be implemented. But that's a purely organizational problem.
Of course, all of above applies to actually saving data to permanent storage. Storing everything in memory is a sin by itself.