I see this question as addressing an informal vs formal issue.
I've never believed in formalism for it's own sake so long as you're responsible.
To be opportunistic you have to be exploiting an opportunity to pay down technical debt for a cheaper expense than if you'd filled a full-blow, self-standing, ticket against this issue. That ticket would require the full prioritizing ceremony. That doesn't make it cheap.
I'll argue that improvements can be made to code that is having a new feature added that isn't strictly required for that feature. However, don't be a cowboy. Talk to at least one person about this before hand. Because what you think is an improvement might not be to others. Be sure you haven't stepped outside of the scope of tests that will be run against this change. Keep in mind that large changes, ticketed or not, make it hard to figure out where a problem was introduced.
Do that and I won't force you to do it all in a separate branch. If you think you've just cleaned up camp, fine. Present it for inspection and be prepared to put back the rocks you thought you could take home. Think about doing that before you decide a separate branch is a bad idea or how many rocks you want to turn over.
P.S. I have a lot more tolerance for this kind of thing when it doesn't all happen with one commit.