Because that still doesn't solve the problem of having to know the local offset to know if a proposed time is reasonable for them, for say a meeting.
It also makes it easier to talk to others, if they say "6pm" you think "dinner time" or "just off work" without having to know the location of the person, at the time they're talking about, which may not even be where they are.
Surely people would just start using some sort of utility that tells them 'people in X are usually awake between these hours'. It replaces an existing problem with a slightly different problem but the net gain is you remove all the annoying edge cases people currently have to deal with when converting between time zones. For example, no longer being confused about how long your flight lasts that traverses time zones.
A utility that converts UTC to a description of what subjective time of day it is... maybe even represented with numbers... congratulations! You've just reinvented local time zones!
This kind of local planning is far more common than long-range travel, and should be optimized for.
For edge cases involving cross-time-zone travel and communication, the solution I've seen implemented most often is to have two date-times shown in parallel. e.g. a flight is from 12:00 Pacific (4:00 Japan) - 14:00 Japan (22:00 Pacific).
It also makes it easier to talk to others, if they say "6pm" you think "dinner time" or "just off work" without having to know the location of the person, at the time they're talking about, which may not even be where they are.