I'm not saying don't consider everything from the outset. That's the reason we have a whole pre-production phase to plan for every eventuality that'll arise during development. You can't really plan the definite controls without testing how the mechanics work first though (you can certainly make guesses of what they'll be, but I don't think I've read many prototype documents that cover control schemes).
Once you've got that plan, you can then focus on the core elements first. Things like alternate control schemes that you don't plan on using primarily for development are something you shouldn't worry about until you've nailed the important bits first, especially if you're not making a massive game for millions of people to play.
There's a very simple way to avoid this issue that torque itself implements. We call them keybinds. They're incredibly easy to manage, store, and change. Even with the most basic of custom made games, all you'd ever have to do is go into keybinds.txt or whatever and change a line of text, and the controls would be different. No need for horrible hard coded keys like most games have.
Another plus is that if you're using a library with controller support (i.e. SFML) you can "keybind" buttons on the controller with no goddamn effort.
Though I do agree keys aren't important at all if you're still working on the basics of the game. Nothing has to be user friendly if it's only you that needs to use it. A keybind system however is still something you want to implement right off the bat simply because you don't want to have to go through all your code changing function calls later.