Tem razões históricas pra isso. Segundo este post (que por sua vez, tem link para a Wikipedia), inicialmente o SQL se chamava SEQUEL (Structured English Query Language).
De acordo com o primeiro link acima, isso dá a entender que a ideia era ter algo próximo da linguagem natural (considerando o idioma inglês). Os exemplos usados lá são:
- "From Employee table e Select column e.Name"
- "Select column e.Name From Employee table e"
E a segunda opção soaria mais "natural" aos falantes nativos de inglês (e como eu não sou, não tenho como avaliar). Concordando ou não, é fato que o inglês sempre teve - e ainda tem - forte influência na nossa área, e este seria apenas mais um caso.
Outro fator que pode ter contribuído é que o SQL no fundo é uma implementação da Álgebra Relacional. Uma das operações é a projeção, que basicamente faz o mesmo que o SELECT (escolhe quais colunas estarão no resultado final). A sintaxe é:
\Pi_{a_1,...,a_n}(R)
Sendo que R é o que chamam de "relação" (que é um conjunto de tuplas - na prática é o equivalente à tabela), \Pi é o símbolo da operação de projeção e a_i são as colunas escolhidas. Se lermos a fórmula na ordem, basicamente temos "SELECT" + "colunas" + "tabela". Seria natural que uma implementação seguisse a mesma lógica.
Enfim, por mais que possa parecer contraintuitivo, é um padrão estabelecido e por isso parece ter resistência para mudar. Vale lembrar que não é uma alteração simples, pois os parsers teriam que lidar com duas sintaxes diferentes. Não só aumenta a complexidade de uma parte crucial de qualquer banco de dados, como poderia causar até problemas de desempenho em aplicações críticas (especulação, claro, mas se aumenta a complexidade de um componente essencial, existe o risco).
Para uma query simples pode parecer uma mudança fácil, mas pense em queries mais complexas, com sub-queries, CTE, etc. Neste ponto eu entendo o criador do SQLite, tem que ser algo muito bem pensado para não impactar as zilhões de aplicações atuais.