Without going too much into detail, such a big deletion has a variety of benefits compared to deleting the ways directly before retracing. Learned this while mapping transmission in FL,GA,SC,NC&AL.
(If wished, I can also go into more detail)

I will not revert the entire edit here, but I searched using the Osmose QA tool for all unconnected poles/towers and restored the ways with more than 10 or so in a row.
changeset/135216271
The rest is going to be properly retraced, just like I did already in the states mentioned above.

Further, I don't see why this is "flat out unacceptable". My point is: Those trashy ways (an actual shame for OSM) were all over the state for 15 years, if they are gone but a handful of power towers will be orphaned for a few months, then that's not the end of the world.
But that's just my view.

Greetings

No idea what "pet nodes" are.
You're not in the position to complain about the revert. You should rather be thankful that I still bothered to fix/filter out things like highway=service/path, I could have just reverted the whole thing completely. The collateral damage would've been your problem.

What about you start using entire sentences to communicate, like a civilized human being?
I asked multiple times why'd you delete those nodes, and you always ignored or dodged the question. Because I don't want to waste my time like that, reverting was the only plausible option.

Because your'e obviously unable or unwilling to explain why you deleted those nodes, I reverted those deletions.

(hw=service->path etc. remains unchanged)

Ok.
And why did you remove so many random nodes from ways?

I still don't understand the "cleanup" you've done here

Sounds good, re-added them.

Note that the distribution voltage in the area is 14kV, so you can add voltage=14000 to other lines you eventually add.

I removed them because they were tagged as power=line, which is wrong. power=line is only for high voltage power transmission.

Theoretically, power=minor_line would be correct, but I think that's very questionable too, if only a few loose stretches are mapped - because it gives a false perception of the reality.
Ilustrative example of what I mean: Someone maps 10 individual parking spaces - but the entire lot consists out of 200.
If someone looks at the data, it looks like such power lines are only here and there, but in reality, they're next to nearly every road.
That's why I deleted them entirely.

If you want, I can restore them, but I don't think that's a good idea.

Greetings

Very old, I know, but:
You somehow left way/33006092/history without tags. Guess that wasen't intended like that.

No idea what you're talking about

I saw this already, and there, it looks like you just deleted some random nodes and thus lowered the quality

I assume you mean those ways avoiding multipolygons?
I don't think it's a good idea to just simply delete them entirely - I properly fixed it by converting them to multipolygons.
Didn't took long using JOSM's "connect overlapping areas" tool.

What exactly have you "cleaned up" here?

Why did you delete all those golf=rough ways?

Hello,
at changeset/133926121#map=18/34.14306/-83.60406, you used the "Apartment Complex" preset for apartment buildings.
"Apartment Complex" is intended for the entire area, individual buildings should be tagged with "Apartment Building". - Fixed it now.

Greetings

This is a siding, not a main track. And please use meaningful comments.

Please use meaningful changeset comments

"Main track" is not part of the name.

Yeah, they also, because they're having the same problem as here.

(By the way, I have no intention to revert any other changesets which add wikidata - even when they're also againest the automated edit guideline-, because a) they unify normal operator which I find to be a very good thing actually and b) dosen't "downgrade" anything)

"Plus, data consumers can deduce much more information from `operator:wikidata` than from `operator`. If, for example, I want a renderer that displays the reporting marks of railroads, I can determine that by checking the statements in the Wikidata item attached to it."

Sorry, but all of those "good reasons" I've heard so far sound like maximum effort for minimal benefit. If I wanted to have something like that within my map/tool, I would write a one-time wikidata query which extracts a table with operators and their reporting marks, and use this to match the normal "operator=*" values.
Something like https://w.wiki/6Rg8
... I wrote this using Chatgpt, all I had to to was to replace the properties with the correct ones - took less than 5 minutes. Another 5 minutes, and it would probably also include all aliases.

Don't get me wrong: I, too, feel it is very important that these "operator" tags are consistent. "CSX Transportation" has been used almost not at all so far, but ok.
But I'm pretty sure that these Wikidata tags -especially on train tracks- cause much more maintaining effort than they would really ever help anyone.