For example, I'm fully against whiteboarding now. I'm pretty good at it, but I think it's irrelevant and ableist (lots of people have anxiety issues and so on). When companies ask me to take a live test, I decline respectfully, talk about all this, and offer alternatives (pairing, take home assignments, review of past work, references). If this doesn't fly, well it wasn't meant to be, and it's better we both found out early on.
Like sure, you're usually going to start the design review with a prepared document that everyone's looked at in advance, but if it becomes contentious, you need people to be able to quickly pitch their alternatives and hash out the various tradeoffs in a synchronous way (eg, not running off and making a whole new slide deck for each stage of iteration).
And I 100% think that both parties getting a feel for how work is done is very important, so I think like letting interviewees have a look at some code reviews, maybe sit in on a retro, do a pair exercise or whatever, this stuff makes sense. And I like your point about "if things become contentious": a lot of teams can fall apart in these moments, and they're kind of a test of the maturity of the participants and the strength of the culture.
I also don't really expect "reverse a string" to be on any interview except the "have you ever coded before in your life" phone screen.
The last one, frankly, makes you come across as a jerk. If somebody spends their interview time telling me I am an idiot or mean or foolish for choosing a particular interview question, that's not going to go well. People who show up to a design review with a shallow understanding of the problem and assume that the other people are just stupid for not doing it a certain way are terrible to work with. Assuming that the other person has a reason for doing something is a better starting point.