I've had the same experience (although not a game-losing move), but frustrating in any case. I chose to draft an opponent's die to seize a location and then I realize I don't have enough influence points to recruit a new meeple. The UI requires me to displace my own meeple from elsewhere, although I would prefer not to.
The frustration in online implementations happens being required to follow through on mistake because the UI doesn't let you back out. These kinds of mistakes don't happen in real life because once you realize the goof, you just fix the move. "Oops, I don't have the influence points to do that. I'll do this instead!"
Reversibility belongs in the bones of the framework
I know we're not allowed to mention competing sites by name so I'll just say another big board game site (hundreds of games) implements all their games with what looks to be a functional (as in functional programming) interface (e.g. Functional Core, Imperative Shell). The mishaps are rare using this model. Even Beyond the Stars, here, which has a good deal of undo to prevent most boneheaded moves, doesn't prevent them all the way the other site does. While BGA has some of the nicest looking implementations, the frustration of being required to "do dumb things" leaves one with a bad feeling every time it happens. It's feasible for a framework to make this sort of goof impossible.
I've had this happen quite a few times on BGA and almost never on the other site. And playing a game for several weeks only to culminate in an epic fail which is more UI than player, stinks.
I know some will say, "know the rules" but one of the reasons one gravitates to online games is being able to try lots of new ones. And when you're learning games you're apt to misunderstand or forget the odd rule—and need a way to rewind.
This is the kind of thing which should ideally be built into the core framework. I'm a programmer by trade. A board game is just an event log (think event sourcing) with an initial big-bang state and a bunch of events mutating that state. Some events provide the user with new information. Those are irreversible (even the other site observes this rule!) and should be marked accordingly. But most events should be reversible, at least until the user commits (e.g. unit of work).
Take Barenpark, implemented here on BGA. It has a try mode which is useful but awkward. When the core translates from an event log with limited reversibility, you don't need a try mode. Every game on the other site I mention has "try mode" built in. Undo exists for each discrete move up until the point where new information is revealed.