I guess I could let it spot when there are less than the page-size of results, but then I'd need to be confident that the JavaScript sorting algorithm exactly matches the underlying SQLite sorting algorithm - taking into account character sets and custom collations and suchlike.
I've been deliberately avoiding adding any JavaScript to core Datasette almost to make a point: you don't need it. HTML pages load faster than so-called "modern" SPA monstrosities. They work really well. They don't require a bunch of extra steps to avoid breaking the back button etc.
But... Datasette provides a JSON API for everything, and supports plugins. There's nothing to stop someone who really wants no-page-reload query execution from implementing it as a plugin.
I myself have built JavaScript plugins for things like bar charts and line charts ( https://github.com/simonw/datasette-vega ) and map visualizations ( https://github.com/simonw/datasette-cluster-map )
So yeah, my personal bias here is that building websites like we did in 1997 is deeply undervalued.
At least with the server being on the internet and the example setup I disagree that the current way is faster or even near a modern webui
"Sorting results of the previous query, click 'Run SQL' button again to query with ${column_name} as the ORDER BY column"
and a "got it" hyperlink to be stored in your session state store of choice upon first click on a column header would probably make it clear.
I find that data/UI tools that only sort the visible results, and not re-populate the paged view of the data, extremely counter-intuitive.
Even old libraries like ExtJS supported easy re-querying the server upon the column sorting event - though it has to be said, many lazy implementers didn't use this feature.