But ultimately it's a culture thing -- if you're hired into a culture that values pair programming, you're hurting your team by not also valuing pair programming, and vice versa (you can't make a bunch of introverts enjoy spending hours with someone giving them guidance over their shoulder).

Honestly, being an introvert here is a hinderance to growth; it's vastly superior to run through a problem as a pair when someone has better knowledge about that problem than you do.

My best guess is that developers just love code reviews. But now that I think of it, maybe they rather loathe writing plain English. Maybe there exist some simple yet more or less formal language that could be used to write design docs?

Instead, people nitpicked to death and tried to one-up each other with findings. There are loooong arguments over completely irrelevant details. There were multiple rounds of review, sometimes changing the code there and back again. People attempted to code into review comments. And the expectations changed every week, there was no stable standard.

It was more about taking control and showing yourself more caring by finding increasingly insignificant things and then insisting on them.

Code reviews can be a good thing or bad thing, depending on what each party brings in and intends to get out of them. Painting them unequivocally as bad is rather silly.

This is not necessarily in conflict with your statement.