I always think of this during responsive image discussions – if JPEG-2000 had caught on, we could have solved that entire problem simply by adding an attribute to <img> telling the client which HTTP byte ranges it needs to request for various sizes. Single-file, cache-friendly, degrades well, and … will never happen.
> Sadly it never took off as storage / bandwidth are cheap and JPEG is so entrenched (especially in hardware)
JPEG proving to be impressively durable certainly was a key factor but I also think a lot of it comes down to naive moves by the community. In addition to the patent situation, there were just basic things like having a huge spec which for a long time was neither freely available nor accompanied by a public test suite.
I work with librarians who have large scanned digital collections and it was definitely interesting to compare the reactions: the users disliked JPEG 2000 because they'd been conditioned to expect it to be quite noticeably slower, unsupported by some of their tools, and knew that they couldn't rely on any two programs actually working with a given set of files until they tested it (http://jpylyzer.openpreservation.org/ has helped catch that earlier).
Meanwhile, the JPEG-2000 standards people & other boosters just tended to assume inevitability, where everyone would drop other formats once they saw how inferior they were. Things like Photoshop removing JPEG-2000 support (first discussed publicly in 2007, dropped in Elements in 2011) had this odd effect where some people expressed considerable concern (http://wiki.opf-labs.org/display/TR/JPEG+2000+support+discon...) but others just assumed it was some sort of unrepresentative quirk.
I cannot help but think that the situation would be considerably different if something like OpenJPEG.org had gotten significant support much earlier. Jasper, JJ2000, etc. were the most popular way to add support at all and they're slow, buggy and generally stagnant so many people had a bad first experience which encouraged avoiding the format.