Re-encoding the JPEG will destroy the hidden bits, so it's very fragile.
At some point in the future you can bet your ass that there's going to be a country that implements mandatory filters on uploaded images that destroy any numerical data that could be encoded into them if it's uploaded by an anonymous user. It's too dangerous otherwise (lol).
There are some papers on it that I haven't read yet which may provide a generic attack that preserves image quality but what about audio? Video? Typos in web novels, ebooks? The list goes on. You can hide your info anywhere. I'm waiting for a future where there's an addon for pgp that takes images as an input and outputs something that looks normal instead of just proudly stating you can't see what I'm saying haha. The best defense is one that isn't seen right?
The flip side is that standardized steganography is far less effective. If you write "FooSteg" that can embed messages in jpeg files, I can probably write "FooStegStripper" that can remove messages encoded with FooSteg.
A counterargument is that it's trivial to write a steganography program if someone doesn't think you're using steganography, but it's much harder to not leave a statistical signal if someone is looking for (an unknown) stegnanography. Tools that are sufficiently good enough to defeat generic analysis are hard enough that the ease of which known steganographic tools are defeated becomes an issue.
I've heard it's possible to detect least significant bit steganography using statistics (like we've noticed the red channel varies from neighboring pixels more than usual) but even if that is possible, and I absolutely have doubts about that, there isn't any way to recover the sequence of pixels or decrypt it.
Then a whole world of steganography appears :)
Which reminds me, when at school we had code-names for various drugs so they could be freely spoken of within earshot of anyone, including parents/teachers. Claude = cigarettes, Harry = alcohol, George = marijuana etc hehe. Worked very effectively.
Maybe in the future people will be using something like Rubberhose FS.
It is old and defunct, but this is a filesystem version of runlevel containers in an encrypted ext2 volume. Runlevel X can read all data at runlevel 0-X but not deeper. Typing in a "bad password" only lead to data corruption of existing data as there was no password check.
This provided plausible deniability in that I could have many runlevels, and "juicy" fake docs to lead people off the trail.