Whilst improvements shouldn't be done ad-hoc without consideration, I think the concept of "left alone" applies more easily to the concept of natural spaces. In code it is really stretching the metaphor to do much more than very basic tasks like renaming or code formatting (e.g. picking up trash). Adding a test doesn't feel like "left alone".

One of the examples in the article is upgrading a dependency. This could easily fall into the category you mention if the upgrade itself is not properly tested. A considered approach would be:

"I want to make a small improvement, oh I see this dependency is out of date and has some minor vulnerabilities or perf issues, or is missing a feature that could come in handy for XYZ. Hmm, there are no tests confirming our assumptions about the current library version, nor are then any tests are our code / systems that use it. I guess my improvement should be to add those tests, then next time someone has the same idea it'll be an easier upgrade"

I am unsure but I also interpret from your first sentence that you may have seen people use this rule as a defence for gold plating (the opposite of KISS or YAGNI). Similarly this should fall under the heading of changes made without proper discussion, thought or consideration.

Otherwise I think we're really stuck, if team members cannot be trusted to properly interpret the boy scout rule without messing up a codebase then how on earth can they be trusted to build the foundation of their company / team / system?