Changing the version of NodeJs can require that potentially - by making entire sets of nodes non-functional (one example being the original . In other cases, it will require replacing one or a few nodes.
There are several examples of nodes that have been deprecated because of broken functionality.
Node-RED (and node.js) updates CAN break things at times.
The cool part on that, though, is:
You know those changes are coming long in advance of them being required (usually months to years).
For example node.js 16 is supported today on node-red - it's end of life isn't until 2024. Get on it now, and that variable is taken out for 3 years.
It is almost trivially easy to stand up another node-red instance in parallel to test these things before migrating.
The breaking changes are exceptions more than the rule.
As far as the RM portability - I see both sides of that argument. One camp says if a rule is working/done, then there is no need to migrate it. Any new functionality is as moot point as the existing rule already works - so leave it alone.
The other camp would probably say, yeah but what if a new feature could streamline/improve how the rule works? Then it has to be recreated? Yup, that's true.
I am in neither camp, as I dislike camping, but I get both ways of thinking.