I was going to answer points one by one, until I realized one major issue kept coming up. (I've also left uncovered e.g. ETAs. I can't help with that; no-one can..)
Main point:
Every coder has a default writing style. They can deviate from it in the moment with effort, and if this happens often enough their default changes. Nobody starts with encapsulation, SOLID etc. skills in their style, so you've learned it, and that's how. But you need to unlearn some of it, including when you refactor. For example, with unfamiliar existing code, you start adding encapsulation: don't do that. Make the minimal changes to understand (what you need to for your current task) - or at a push clarify, but even that's not the team's current priority - not to make the final result the cleanest comprehensible option. If a line made you think "what does this do?... Oh, that's what", you can change it (if the pause was long enough).
Oh, one more thing:
When handling existing bad code, I tend to:
- Not know what I am going to break with my changes
If you don't understand the code well enough to know a change is safe, you're in good company. Test, test, test. No, I don't mean write new unit tests: that's slow. Either existing tests will cover it, or your team doesn't rely much on them. What I mean is run some code, then see if anything goes wrong; and when (not if) it does, make whatever changes you realize are necessary. The fact you'll feel you fixed it when you're done is the best unwritten counterpart to a unit test a quick, dirty coder is going to get.