This is no different than if recipient of the secure message shares the message in plaintext. The problem is a discipline problem not a technology one, and the solution is the same in both cases.
The expectation is that what happens inside Signal is secure, and the features Signal provides are secure. If the idea is that nobody is going to enable this feature, then why build it? If the idea is that many people are going to enable this feature, then this entire cryptographic protocol is meaningless.
I've yet to see a protocol that lets you convincingly insert fake messages into both sides of your own chat history, especially in a way that isn't detectable by say, sqlite rowid order, but that would be an interesting idea for where to take this sort of thing.
If you are just looking for "secure(TM)[X]", you are making a mistake somewhere anyway.
If your life or livelihood depends on it, you learn what the impact of every choice is and you painstakingly keep to your opsec.
Somewhere between the two user action becomes a necessity. You need to judge where that point is for you and take responsibility for it because nobody else can guarantee it.
Show me a company anywhere that can provide security without user thought and deliberate action. It's a fantasy to believe anything you don't have to think about isn't theater. Hell, if you aren't thinking about it, you're one of the actors in that theater.
With disappearing messages off it was already reasonable to assume that a compromise of a counterparty's phone would result in exposure of all previous messages, so enabling backups wouldn't expose you to new risk.
That would cater to those who want to keep their chat history forever without exposing those with disappearing messages enabled to new risk.
But practically, it probably has more risk as people bypassing employer or legal controls think it’s “secure”. So they have conversations that they wouldn’t have.