standards - and for those that do work a lot on this and use tools to help with coding, putting the alias can be automatic, and expanding the columns will also include the alias if one is given from start - so no typing saved at all.
and should you need to add another table to the query, those columns are already aliased and saves you time and also prevents errors where you could pick up the alias/column from the other table.
And... in many cases where you didn't do it from start, and you add a new table, many people will then NOT alias the columns unless they are common to multiple tables - and that leads to people in the future having to figure out which table the does the column belong to.
What standards? In any case, any standards I've seen regarding aliasing tables refer to the undesirable practice of using a single letter as an alias which, in a complex, multi-join SELECT, makes matters worse rather than better.
If you don't provide disambiguating table prefixes to columns with names shared across multiple tables then the SQL will throw an error. In the simple example to which I referred, it was one table and therefore no need for an alias at all.
In your final comment, I agree that not prepending the table to the column in the SELECT where there are JOINed tables is sub-optimal; in my practice I use that actual table name which is a whole lot more useful than a single letter. That way the reader can see at once which column belongs to which table.
YMMV of course.