I'd extend #2 to any change, not just non-trivial. It's the classic Kent Beck tweet, "for any change, make the change easy (warning: this may be hard), then make the easy change"
Fixing my mental model of thinking about refactoring as a separate thing from "normal" development was key for me. Once I viewed refactoring as a thing that you do all the time as part of development, then I stopped even asking this question.
I somehow ended up doing the same. Probably as a result of too many failed heroic attempts at modifying read-only code in one big go.
Now any heroic modification of code comes in a series of incontroversial, isolated and testably idempotent modifications, followed by a minimal change to business logic.
Fixing my mental model of thinking about refactoring as a separate thing from "normal" development was key for me. Once I viewed refactoring as a thing that you do all the time as part of development, then I stopped even asking this question.