A contract is just a unification of SRS and RSR with the same commands and the idea that you want to manually confirm the transaction will be signed. While this is possible in the old flow, it’s often automated for the receiver. I believe some of this desire to automate this part comes from the fact that people are used to Bitcoin-like transactions which don’t require the receiver to do anything to process a payment. Obviously, I can’t speak for others, but my view is that requiring interactive action is a bonus for a very simple reason: both parties see the changes that are about to happen before they sign off on them. This eliminates all kind of output injection attack (e.g. dust attacks, taint attacks,…) which are impossible to prevent on other networks because actions are not signed by all the parties involved. Moreover, both parties checking what gets signed can also catch a mistake before it’s published on the network. As this post explains, there’s some other small details that are changed in this flow like txs defaulting to payjoins, kernel cost is split equally, each party pays for their own input and output fees, late-locking by default etc.
Whether people end up calling these contracts, multisigs, or something else is less important than showing the sign step. Rather than trying to hide the sign step, let’s accept that it’s inherent to Mimblewimble and try to take the advantages it can offer.