While it's true that a version transition like that hasn't happened again, it's utterly naive to think that just because there are newer versions available that they would be suitable for an industry such as ATMs or banking, which require serious reliability. There have been periods during 2.6 and 3.x where, for instance, ext4 drivers would silently corrupt data for a few stable patches.
You're talking about FAR beyond the notion the notion of "long term support", into "indefinite, forever, and guaranteed stable/regression-tested/quality-assurance-tested" support on one particular version for at least the next 10-15 years. Version upgrades (like from 3.2 to 3.3) would be completely out of the question because it could introduce a regression and take down a nation-wide ATM network or silently corrupt transactions without any way to easily debug and fix it in a short period of time. Every ATM also has to be effectively interchangable with any other ATM. Version changes break the ABI and require any external modules (likely required for an ATM) to be recompiled. The slightest mismatch between perceived ABI between different modules will cause corruption and/or crashes. So you are, in essence, only talking about security fixes on an already-reliable version, and the security fixes can't change any data structure sizes or perceptions.
That is basically what Windows Embedded versions offer. The kernel layer ABI sometimes changes in consumer Windows versions (and includes enterprise and server versions) due to compatibility or security fixes. It's still the #1 cause of BSODs because of antivirus or other security software.
The linux kernel's QA is basically "if it compiles and looks remotely OK, it's fine to put in a stable version".
FreeBSD would be a much more appropriate target for such a device, due to strong QA practices (everything must be tested) and a total commitment to maintaining both the kernel and userland ABI for an entire major release version cycle, except that of course it's more or less only available for x86 (which is one of the reasons why Sony put ORBIS right over the top of a FreeBSD 9.x base).
So other suggestions on this story in general about embedded-specific OSes where you can buy upstream support forever (such as QNX) are entirely correct. Linux has to be treated with an extensive set of rules that nothing else does. Newer Windows Embedded will have to be replaced too often and takes far too long to boot or service.
Once you commit to an ABI, though, that's it. The hardware can't change (except possibly external/add-in peripherals that are optional), kernel modules can't be recompiled. Any versions of any libraries won't increment. System services and other binaries also likely will rarely change, only for serious and required fixes that have been extensively tested. But any individual binary or library on the system, which includes any kernel level stuff, has to be completely and seamlessly interchangable with any other. That may well be a binary that's 15 years old, or comes from 15 years in the present-future. That's how all of that works. If it doesn't work that way, it'll cause serious problems and chances are the company as too cheap to have a "plan B-H" to get things working within the hour.