First, be careful with the phrase "maintain high coding standards and beautiful code.".
Regarding Standards
Who decides what the standards are? There are many code-style standards out there, and most are equally valid, as long as a single one is used consistently within a codebase. If you are the product owner, manager, or the undisputed most senior developer, then maybe you do have the discretion of picking the standards, but you have to pre-establish them rather than start making decisions on PRs. The documentation or readme files of the projects should make clear what the standards being applied are. In general, it is not a rule if it is not written.
Regarding 'beautiful code'
While I myself enjoy beautiful code, I see a red flag on any reviewer who justifies his comments with remarks like "this looks ugly", or "I'd be happier if you did it some other way". If code is messy and harder than necessary to understand, that can be a valid point when you can provide elegant alternatives.
But remember that everyone likes to have some degree of autonomy in their work. If every code you review needs to be done "your way", then you might have started to (unconsciously) believe that the code is meant to please you rather than to achieve some company goal and deliver some customer feature. So unless you own the company, keep in mind that "pleasing you" is not the goal of any code. Furthermore, if your reviews basically throw in the garbage the work done by other people, they will not enjoy doing it in the first place, they rather say "then do it yourself next time" (and I do note here that the goal of the code is also not to entertain the coder). In general, up to reasonable limits, and as long as requirements are met, the preference on deciding some implementation details should belong to the person writing and maintaining the code, rather than to the person reviewing (some exceptions on this to very experienced reviewers, who should have management or clear leading roles or are responsible for cohesion in a large codebase).
All that being said, and just to be clear, you do not seem like an unreasonable reviewer, but parts of your questions can raise red flags if extrapolated a lot (which I'm doing for the purpose of this answer).
Regarding the Wikipedia example
Avoid 'correcting' what is not wrong. It is as simple as that. If it meets requirements, if it does not breach any written/established standard for the codebase and if it does not introduce any bug or security flaw, then it is not wrong. If it degrades performance, then you should really have clear performance metrics to show and prove your point.
You can, and maybe should give suggestions, but as others alluded, you should mark them clearly as suggestions or as opinions so that the author of the PR knows that he/she has the option to simply ignore your remark. I worked on a project where code reviewers had the obligation to assign a "relevance" rating to every comment they made. The ratings were either "critical" for serious stuff that should be corrected right away, "regular" for usual stuff that needs correction but has very low impact, "minor" for stuff like naming conventions that had no functionality or performance impact whatsoever, but had a mandatory correction and finally "Information" for stuff that was just an idea for an alternative solution or an opinion.
While people generally accepted those "suggestions", the fact that they were clearly stated as optional prevented a lot of pain that would ensue on pointless discussions such as "this could be marginally better but would also mean a lot of rework", "If you'd like to adopt this standard here, then there are 134 files which would also need to be updated", "I have a different opinion and I'm the one doing the code here" and so on.
Regarding the global variables example
From what you've written I cannot form my own opinion on who's wrong or right (if anyone) in that case, so I'll assume three cases:
IF You are right: Then you may need to communicate better and have a well-established point. You need to teach the person a lesson, not in the "vengeance" sense but in the "classroom" sense. Instead of fighting over PRs, sit with him with a computer nearby and make a presentation showing objectively why he is wrong. Preferably write code that proves he's wrong and run it in front of him. For example, if you need to explain that you need a specific copy operation to copy a list on Python, then write and run an example for it as as in here, don't simply tell him that "what he did is just plain wrong".
IF you are wrong: You may find out this is the case during the exercise of preparing the aforementioned presentation. This is great because you've done some understanding before criticizing. Always keep in mind that everybody (including you) makes mistakes. And there are different levels of tolerance towards different types of mistakes. If you are going to publicly claim that someone is wrong (you've mentioned public PRs), then you need to be very much sure that you are right. In case you aren't, a personal talk where you ask the person to explain what he's done is maybe more than enough for him/her to enlighten you (or in the previous case, they might notice their mistake themselves while attempting to explain).
IF neither of you is wrong or right: Then you are discussing matters of opinion. Ask yourself: Why are you discussing a matter of opinion? You apparently don't enjoy exchanging ideas with this particular colleague, since you expect him/her to simply comply with your suggestions rather than try to learn something from what he/she answers to you. Why does it matter if it was made in the way he/she prefers rather than the way you prefer? Does it actually have an impact on other pieces of the codebase? Then point this out, so you share the relevant information with the whole team to call for a decision that affects more than the single PR written by your colleague. Otherwise, remember as before not to correct what is not wrong.
Regarding public PR discussions
There is an old adage that says "Praise in public, criticize in private". Public comments on a PR are supposed to be documentation, not discussion let alone criticism. Mistakes happen, and not writing anything to any PR will make it look like you are not doing any review work at all, hence why PRs reviews are (sometimes) public. But if you feel bad about discussing in public, so does the other person, and there is no surprise that he/she gets defensive. You are criticizing in public. My suggestion is that if anything gets messy in the review you should have written notes of your own, and talk in private with the person, either through a video call with a shared screen or a meeting room, then go over your notes, explain your points and reach agreements on what should be done on the code. Then, these agreements can be posted as the PR review, but preferably write them with the other person present and agreeing on the content. This avoids getting the person too defensive and separates the fighting points for private while the relevant/straightforward remarks can be put on the PR review. This may be time-consuming, but if you took note of the previous points, this should all be worth the time it takes.
Regarding the "as long as it works" attitude
Yeah, I get this part is difficult. If you are in a management position, you have a lot more power to change this mindset. If you aren't, then you need help from management. A few suggestions that may help:
1. Files have owners. Create a rule that each file in the codebase has an owner. If changes need to be done in a certain file, the owner will do it. If the code broke in that file, the owner will fix it. Someone other than the owner is responsible for reviewing it each time, the reviewer should change periodically. That does not mean the owner has the last word on how the code works in that file, but it at least makes clear that poorly written stuff will come back at the person who wrote it. Reviews remain important so that no one produces hieroglyphs to make him/herself unfireable.
2. Good code means replaceable people. Managers hate having unreplaceable people. If code is too poorly written to the point only the author (if anyone) understands it, then this becomes a liability to the code. I've heard about cases of entire codebases basically dying because it was not worth the effort to maintain it. And this favors the poor performers rather than the people looking up for promotions. That is mostly an argument to get management on board with improving code quality.
3. Consider having a separate QA department. In some companies (think mechanical engineering rather than coding), there is a quality assurance team whose job is to verify compliance with requirements (both functional/performance but also quality and standard adhesion requirements). These are normally guys that do not answer to a manager, but rather directly to a director of operations, so that they cannot be silenced or retaliated by a manager pressed to meet a deadline. They don't come up with the rules, they just enforce them and check if those are being followed. Maybe a squad like this should be performing reviews rather than peers.
4. Let it be. As mother mary said, when finding yourself in time of trouble, let it be. You might have thought that the previous suggestion would be way too overwhelming and exaggerated for your company. But here's the news: Maybe your code standards or preferences are also too much for your company. In many businesses, time to deliver features is much more critical than code quality. Perhaps because if they grow enough the entire codebase may need to be fully reworked on a more scalable solution, perhaps because some performance issue has very little impact on profit and customer experience but additional features would open new markets and make the product compete against the super-hot expensive alternative that dominates the segment. Also, the company may be having a hard time hiring developers, so keeping the ones they have happy without increasing salaries too much is becoming a relevant concern. All those are reasons why many startups have surprisingly low coding standards, that will only improve once the company gets acquired and the new shareholders put some adults in place to enforce sustainable and rigid coding practices. And even then, some colleagues of yours will prefer to quit the company for another one in which coding is a much less strict activity.
