See LINQ. There they had the opportunity to fix it and it works just great.
This nullifies some other common sources of confusion, such as which statements are executed before a GROUP BY and which ones after (and why HAVING exists as a keyword). It's also similar to how CTE syntax is generally much more readable than subqueries.
This declarative property also provides a (somewhat weak) motivation of why SELECT should come first. Precisely because it answers part of the WHAT, i.e., the schema of the result.
However,
SELECT a1,a2,... FROM Table AS t WHERE Condition
[(t.a1,t.a2,...) for t in Table if Condition]
SELECT is also analogous to normal loops:
foreach t in Table
if not Condition: continue
# Use t.a1, t.a2 etc.
So, I will start with a SELECT * FROM myTable t, then go back and replace * with t.<columns appear here>.
I'll use the same in other places in the query like WHERE conditions.
I use DataGrip at work and it can complete the column names without knowing the table name, so it ends up not being a problem.
If the query is simple enough that a natural join would work and you aren't doing FROM clause aliasing (which can be useful to make reusable queries self-documenting), sure.
For more complex queries and obviously any time table or column aliasing are used, that becomes somewhere between less likely and logically impossible.