Fresh out of college, and knowing very little about the Real World, I got a job making
computer games. I learned a lot there: how to estimate schedules, why I should make
smart goals, how taking a vacation during crunch time can get you fired.*
And I learned about the computer game equivalent of beta reading: playtesting. I remember one tester reported a bug that crashed the game, but none of us could reproduce it, meaning we couldn't fix it. So we let it go, until one day our manager asked us about it.
KEN:** What's with this crash bug? Tester reported it like three months ago.
DEVELOPER 1: It's a random bug. Nobody can reproduce it, but it doesn't seem to happen very often.
KEN: You guys need to track it down, top priority.
DEVELOPER 1: Even Tester doesn't know what causes it. You want us to work nights on a bug we might never fix?
DEVELOPER 2: It's not a big deal, Ken. There are like ten playtesters who've never had the bug, and nobody can reproduce it. It probably won't be a big deal when the game goes live.
KEN: Then think of it this way. If the game crashes for one out of ten playtesters, then when we sell 100,000 copies that's ten thousand people who will get mad and return our buggy game.
Long story short, we fixed the bug, and I learned a valuable lesson about percentages.
This is why it's important to listen to your beta readers too. If only one of them says your villain is a cardboard cliche, it's possible they just don't get it, but it's also possible they represent a significant percentage of your future readers. (And anything two betas agree on is a virtual certainty).
So in general, unless you KNOW why you wrote something a certain way and you KNOW the commenter is wrong, listen to your betas. Chances are they're not alone.
* Not me. Another guy. And it wasn't so much the vacation that got him fired as the fact that his code never worked, no matter how much he insisted it did.
** We had 2 or 3 managers over the course of the project. They were all named Ken. Not joking.