The shallow_user type contains only fields that are "fast" to fetch, as it's always returned as a member of other (potentially expensive to fetch) types.
Accordingly, we can't add any fields to
shallow_user that aren't "fast" and in generally, won't add things that aren't really commonly needed. I don't think the
last_access_date is required often enough to take the perf hit.
As to the reason for separate user and shallow_user types, if we didn't have them it'd be far too easy to craft queries that include too much of users to be reasonable to execute (trivial example,
/search with a tag and all user fields would hit something like 5 tables in the cache-miss case on top of actually running the search).
We could use filters I suppose, but we'd be in an awkward situation where certain combinations of fields would have to be forbidden. Simpler to just have a different type, at least in my opinion.