All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it?
And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.
It's not too unreasonable to assume that a given ancient program would have logic to differentiate between "This is a jpg and I know what to do with it" and "this is a something else and I don't know what to do with it" so it will technically handle webp images safely while it may not safely handle something that claims to be a jpg but apparently is not.
* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything
* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.
That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.
And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.