I understand that there was once a time when the cost to supply and maintain Adobe Analytics was based directly on the number (and size) of server calls being processed and stored. I would guess that this is no longer one of the main operating costs in providing and supporting Adobe Analytics client companies.
I'm not saying that bigger companies with higher volume shouldn't pay more than smaller ones with lower volume. But, the strict 1:1 relationship between server calls and dollars presents a perverse economic incentive that twists implementation design and methodology in ways that don't best serve the goal of providing good information for analytics.
The primary example of this can be seen in the implementation of a product detail page on an e-commerce website. We have a few things that we might want to track on this page:
The load of the page itself (for AA traffic reporting, Pathing, etc).
The product view for the primary product (or products on the page).
Impressions of cross-selling products served from a 3rd party service (e.g. Rich Relevance, Certona, Adobe Target).
Product Rating and review information served from a 3rd party server (e.g. Bazaarvoice, or PowerReviews)
Any other latent 3rd party tag info relative to the product or customer which may be loaded asynchronously.
If cost were no object, I would argue that it is a better design to send an s.t() (page view) tag to AA for #1 above and send s.tl() (custom events) for #2-#5 above.
Since cost is a factor (driven directly by server call volume), as an implementer I am forced to suppress the page load (#1 above) and write code to wait for events #2-#5 hoping to consolidate all the information into a single server call.
This leads to less accurate reporting since the delayed page view tag is recorded less often.
It also leads to more complicated implementations which are harder to maintain.
It is a mindset based in the past, based on synchronous, monolithic, server-managed websites. It does not translate well to Single Page Apps, or microservice/component-based design patterns.