No, that would work very similarly to the greedy version. The backtracking happens because the \d gets matched to the '1' and the whole thing has to be rolled back when the $ attempts match and instead finds '2' (this would happen again if there were more digits for \d to speculatively match on). So the backtracking is not caused by the laziness or greediness of the \D* ; we really do want to gobble up all of the non-digits.
On the two options generally:
/(\d)\D*$/
is problematic if you have a lot of digits, while
/.*(\d)/
is problematic if you have a lot of text after the last digit. Both could potentially be optimized by the engine to run right-to-left (the former because it's anchored to the end and the latter because it greedily matches to the beginning), and then both would do well. I'm not sure if that happens in practice.
Overall, I prefer the latter, both because I think it's clearer and because its perf characteristics hold up under a wider variety of inputs.
Edit: how do you make literal asterisks on HN without having a space after them?
In this case when finding the last match from the end, would the lazy quantifier reduce backtracking? e.g. /(\d)\D*?$/