Doesn’t sound crazy to me!
It might be because of the rollback netcode itself.
(It’s accepted that both consoles already struggle with the “busier” stages, right? I’ve been led to believe that they do drop frames during offline play.)
Every time a rollback occurs, the engine has to (re)load a new (old) game state. The hope is that this will take less than a frame to accomplish, i.e. it will be virtually instantaneous.
The more deeply the engine has been set up to accommodate rollback netcode, the less it should have to reload to accomplish a rollbsck.
The extreme example is PC GGPO, where the netcode has zero access to the inner workings of the game itself so, everytime a rollback happens, the emulator is actually loading an entire game savestate. As I understand it, this is why 3S (noticeably imperfect) runs worse than ST (practically flawless): the emulator could load ST savestates a lot faster/cleaner than it could load 3S ones.
Depending on exactly what (how much or how little) SFxT actually reloads for a rollback, it’s conceivable that a busier stage could require more work (time) from the system. It would then make sense that the netcode (functioning “properly” and as intended) could indirectly disproportionately exacerbate the degree of inherent (offline) frame-dropping that the busier stages already suffer from.
If you read this and don’t understand me, please don’t stop loving rollback netcode! It is still incomparably better than the old alternative (delay netcode).