I would still consider them to be timebomb bugs, though. Even if you're developing for a restricted set of hardware, newer versions of that hardware could very easily violate some corner-cutting assumptions in the future. I would rather spend a little more time now to get something right and future-proof, rather than pass the problem onto future-me, who likely won't have the context anymore to find the issue quickly, or, worse, future-someone-else, who doesn't have the context at all.
Yeah, over a long enough time window I think portability and correctness will always come back to bite you. Apple could've saved time by making Darwin only handle one processor nicely, but then the Intel transition and ARM additions (iOS is still Darwin, after all) would've hurt more. Windows coasted on x86 for a while, but now that they're targeting ARM I'll bet they're pretty glad that it was originally built to be portable. Code that only works on the exact system you need today might be good enough sometimes, but if you survive long enough you'll want it to be more flexible than all that.
EDIT: I should add, this applies to applications, not just OSs. If you're an Android dev - will your app run on Android 15? Will it work on ChromeOS? Will it run on Fuchsia? If you're writing Windows software - will it run on ARM? If you're making webapps - does they work on Firefox? And maybe it's not worth the effort, especially if you don't plan to be selling the same software in 5 years, or maybe you think you can just deal with those things when you get there, but if you plan to still be in business in a decade then you should plan accordingly.
