I agree with you both to some extent. It's all anecdotal though, really.
I think a fair point is that there are common idioms that you need to learn one way or another. Whether that is formal training or intuition or just plain force of will, you need to come to understand the meaning of what you are looking at and not just what the individual instructions are doing.
Otherwise, it's a similar idea to saying, "nobody needs to learn how to read music because look how great Jimi Hendrix was and he couldn't".
Right, I'm not saying that learning software engineering wouldn't help. I'm specifically pushing back against "it's significantly harder without some engineering background", since a lot of good reverse engineers I know still don't have a good software engineering background. Being able to identify program constructs and idioms from the programming side instead of the reverse engineer side is definitely one way to do it, but I don't think it's the only way and I'm not sure is even the best way, since a lot of programming details are surprisingly irrelevant for RE so going through a full CS degree program will also spend a lot of time teaching you things you don't need to know for RE.
My point was about relevant engineering background for a particular task. For example, if you're trying to binary patch something, having prior assembly programming experience would help a lot, but knowing the runtime complexity characteristics of various sorting algorithms wouldn't.
I'm not suggesting that aspiring reverse-engineers need to pursue a full-blown CS degree first, but most reverse-engineering activities usually have at least one counterpart engineering activity. You can power through without learning it first, but I'm not convinced that it's easier or faster to learn that way.
As for me, I've spent quite a lot of time doing low-level software engineering beforehand (stuff like OSDev, bare-metal programming and GDB debugging sessions with missing symbols...) and I've picked up on reverse-engineering very quickly I believe, thanks to lots of relevant prior engineering experience. Had I spent my time making cracks and mods instead, I highly doubt I would've been able to later pivot towards software engineering that easily, due to a lack of foundational CS knowledge.
I think a fair point is that there are common idioms that you need to learn one way or another. Whether that is formal training or intuition or just plain force of will, you need to come to understand the meaning of what you are looking at and not just what the individual instructions are doing.
Otherwise, it's a similar idea to saying, "nobody needs to learn how to read music because look how great Jimi Hendrix was and he couldn't".