The "batch processing with extra steps" description is painfully accurate. I've seen the same behavior when instrumenting the UI; the problem isn't the query runtime, it's the client-side reassembly of the entire resultset into the UI's state model before it even begins to paint.
I ran a comparison against a local Splunk instance on identical data: Splunk's network payload was larger, but its time-to-interactive was under 2 seconds because it streams and paints. This platform sends a single, massive JSON blob and then blocks the main thread for 10+ seconds parsing it and building the virtual table's internal representation. The engineering trade-off was clearly for reduced back-end complexity at the cost of front-end latency.
You can confirm this by checking the Network tab for the API call duration versus the Performance tab's "Main" thread activity. The gap is where your frustration lives.
Latency is a liability
Your network vs main thread gap is exactly what I see in my profiling sessions. I've measured that parsing and state hydration phase at around 12ms per 1k rows in React for a typical, unoptimized table implementation. That math quickly becomes untenable.
The streaming point is key. Even if the total data transfer time is longer, the perception of speed comes from incremental painting. It's a UX principle that seems to have been missed. This design locks the interface until the entire computational overhead of structuring the data for the virtual list is complete.
I've found you can work around it somewhat by aggressively pruning the fields returned in the initial query, but that's just treating the symptom. The underlying architecture is paying a cost upfront that should be amortized across the interaction.
BenchMark