How to deal with "code first" engineers who are overkill with code quality?

Sorry to hear about all this, particularly your reputation hit. I firmly believe that you should be both (focused on shipping great products efficiently to users while also caring about code quality), but there's definitely a balance to be struck here which seems to have been missed.

That being said, the best way to approach any solution like this is to have empathy. Genuinely try to see the world from their shoes and play a bit of Devil's Advocate - It's always far better to build a bridge instead of burning whatever you currently have and trying to find another way around. Ask yourself these questions:

1. Is this engineer stretched super thin? - They might be slow and angry because they're the only senior or staff engineer on a team of 15+. Even at FAANG, I have seen teams like this where 1 person is the gatekeeper for everyone, which leads to them getting burnt out and taking this out on everyone else with their grumpiness.
2. Does this engineer make efforts to leave feedback proactively? - Proactively = before the code is written and the pull request is out. If you see them commenting on tasks and system design docs before code is written, that's good on them and is a sign that the team can figure out a way to plug in better. If you don't, this engineer really needs to learn how to channel their feedback more productively.
3. How is your relationship with this engineer overall? - Do you eat together at lunch? If you've ever talked to them 1 on 1, how's the vibe? Have you done anything in the past that might have offended them before and you didn't realize it? Have they done anything in the past that was actually quite nice for you? (i.e. there is a softer side to them you've seen before)

All of these questions are just important food for thought - I'm an outsider without enough information, so I'm not really here to "pick sides". My goal here is to encourage introspection and figure out how all of you can find a graceful path forward together. For example, I don't see this engineer getting fired as a win - That feels too acrimonious.

All that being said, here's my tactical advice to improve the situation

1. Talk to your manager! - Given that this is a team-wide problem, you absolutely need to tell your manager. Better yet, talk to your teammates who you also know are unhappy with the situation and all of you can talk to the manager together as a united front, either in a group chat or a meeting (or both). The ideal path is that the manager delivers all of your feedback in a way where this engineer is receptive and betters themselves.
2. Act super proactively - Scope out your coding tasks in detail beforehand and share it with this engineer. Follow the advice from the code quality course starting from this lesson here: https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/sweat-the-details-call-out-edge-cases/
3. Time-box decisions - I have been rug-pulled so many times on all sorts of decisions. You simply need to put your foot down to really solve this. If there's an open discussion point on your technical approach for a project, say "Hey everyone, we need to make a decision on this by X day in order to hit the deadline. Whatever we have by X day, we are going with that, and it cannot be changed". And of course, you make this easier for everyone by outlining pros/cons in great detail and suggesting a default course of action.

1. I +1 Alex in re: engineer being stretched super thin. I had take longer to make sure we were making the right architectural decisions for projects we were going to spend a substantial amount of time, money, and effort in before deploying into production - sometimes that meant gatekeeping because something else on the timeline working with non-technical business units (and TPMs etc.) dictated such that I wouldn't be able to move as fas into integrating other external APIs, simply because our code base was not ready and we were stuck in earlier development phases of the product anticipating other long-term decisions so we wouldn't build something hackathon-fast scrappy on the fly. I know that sounds like a perfectionist mindset, especially for someone that wants to 'move fast and break things,' but infrastructure wise, it's important to think a bit more deeply (be more thoughtful) and this can take sometimes a longer amount of time than other junior developers I have noticed and manage, have a large degree of impatience and actually for hte most part, don't anticipate the whole picture of what they're building, only the teeny-tiny piece they're contributing, so they don't know how to anticipate a larger chunk of time something will take to deploy.

2. I agree with Alex and Charlie on this one about rewriting PRs - this is something I've asked junior members of my team to do (I've managed back-end engineers, front-end engineers/design/creative hybrids) and so it is nothing personal here, sometimes as a tech lead/EM you have a specific style/way of running and have to repeat yourself.

3. +1 Alex on time-boxing decisions - having a final deadline for a feature to go out no matter what vs. just pushing things to next week/month/quarter and being clear about that via email/Slack/Discord helps people know 'hey this is due,' and allows people the ability to give their input/feedback with something that is time-bound but open. I also think that your EM should be with a TPM really clear about the milestones you need to hit along the way, but even before that be clear with some sort of GANTT chart (or whatever you want to use from Jira/Notion/PM dashboard of choice) what expectations need to be met for themselves and everyone else, that way you're staying on task and not lagging on one thing. Perhaps your EM was far less transparent and only needed to have a few certain things done with the highest level of quality before feeling whatever code you/others was doing was fully ready for production/deployment.

Some good questions to ask are: what are the negative long-term consequences if the code gets in, and how easy is the decision to reverse?

I do sympathize with both sides because there are situations where you need to write well structured and clean code, but there are also situations where you can be more lax in code quality. The more engineers that work on the code and the more users you have, usually, you'll need to show more discipline in your code quality. If there is no discipline, engineers will make up new patterns for solving the same problem, or you'll end up deploying a lot of buggy code.

If you are working on the first iteration of a new system, it does make a lot of sense to take the time to make sure that the code is readable, elegant, and modular because there will be other engineers that will mimic the pre-existing pattern. The code will usually start to degrade over time if the quality expectations aren't met.

There are probably some things that can be improved on both sides:

For the reviewer:

the type that will ask every lesser ranking engineer for rewrites from every PR

I'm not sure how extreme of rewrites they are requesting, but if there is an existing pattern in the codebase for how something is done, it does make sense to keep that existing pattern throughout the entire codebase.

When an engineer first joins, it's not too uncommon for them to have to rewrite a lot of their PRs because they are unfamiliar with the patterns from the codebase. The request for rewrites usually starts to settle down after the author gains more experience with the codebase.

takes a week to review small tickets

This isn't good because it blocks the product from moving forward. There should probably be an SLA on how quickly code needs to be reviewed. I've worked at a company where we'd track how many PRs would miss SLAs, and it was used to evaluate the performance of a team.

For the code author:

the type that will ask every lesser ranking engineer for rewrites from every PR

I would try to write smaller PRs to get the reviewer to sign off on the code quality.

I would also set up a meeting with the engineer to let them know about your solution so they can sign off beforehand.