Let's start by defining a backroute, for those who may not fully understand what it is.
A backroute is commonly understood as "any solution which bypasses the designer's intended solution." There is a grey area, because sometimes such solutions may be just as ingenious as the intended one, and can therefore be accepted as an "alternative solution" rather than a backroute.
A backroute, more distinctly, is a solution which is generally undesirable from the point of view of the designer (and, sometimes, even the player). It completely unhinges the level, either by taking a ridiculously simple route that the designer missed, or by not "getting the trick" of the level and instead using the skills to craft a more conventional solution. In the worst cases, they rely on glitches, are ridiculously fiddly and are usually only possible on game engines which allow fine control and/or exploitation of broken game mechanics.
As far as the latter goes, the game engine should indeed be as glitch-free as possible - but not for the purposes of backroute prevention. The goal here should simply be in-world consistency; if a game has created a set of rules, its mechanics should of course adhere to those rules in all possible cases, in order to create a world that level designers and players can understand and interact with on equal terms.
Beyond this, I'd like to take issue with the ongoing notion that "the engine itself should be preventing possible backroutes" because it comes up very often in debates and is a go-to reason that can potentially derail many otherwise good ideas (such as new skills, or skill behaviours) if given too much weight.
Preventing backroutes is the job of the level designer, not the game engine.
Ideally, the game engine should provide as many options as is possible, limited only by imagination and preference, and it is then up to the level designers to construct levels within that world.
The very act of designing a level is itself a challenge to other players. You're saying "there - beat that!" If the player then solves the level with an unintended solution (or, indeed, a "backroute"), they have beaten the designer, who must then either accept the solution, or fix the level. Under no circumstances should the game engine be necessarily helping or hindering the designer or player in this process - ideally, it should be an entirely neutral entity in the equation.
Backroutes are not only entirely valid ways to solve a level and beat its designer, they are also an invaluable resource for alternative solutions, challenge solutions, interesting level statistics, and can even provide ways to find completely new tricks, which can then form the basis of other levels (which, if not carefully designed, will then likely have backroutes of their own!) In short, they are not necessarily a bad thing.
They exist as linchpins to learning and progress; however, this learning and progress should ideally all be happening after the fact of the game's creation, informing designers and players of fresh possibilities. They should not retroactively inform the design of the game itself, other than in obvious cases where it exposes an actual flaw with the game, e.g. destructable steel.
We love to hate backroutes. They frustrate us as designers but encourage us as players. And, as long as the game is fairly designed, they are inevitable. Seeking to design the game to rule them out is both futile and self-destructive as it removes an invaluable part of the player/designer equation. They ought to be celebrated rather than maligned and avoided, because they inform future design within the world in which they were created.
I anticipate that not many people will agree with this, but that's exactly why it needs to be said.
