Yes, I think the practice should be different for bugs than user error.
A bug is still a bug - it shouldn’t be happening. For the time it would take to consider and author self-deprecating microcopy, would it not be better to fix the bug? (Maybe that’s moot if the issue is in someone else’s hands or an external dependency or something…)
Also, you mentioned you’re receiving mixed feedback about the error messages - is that purely through the interviews you initiated, or have you received unsolicited comments about it? I ask this question because the challenge with soliciting feedback from people is that they’ll often synthesize an answer for you even if the topic wasn’t even on their mind a moment ago. Then we’re getting into hypothetical or sometimes espoused reactions, to your point about bias. And of course people in those situations may also moderate what they say because they want to be nice.
Is this an internal or customer-facing product?
I ask this because I think it would also inform your approach to the tone of voice. You can probably get away with more experimenting if it’s an internal app.
I like what Nielsen Norman Group has done with setting up 4 dimensions of tone of voice, each dimension being a point somewhere between pair of opposed adjectives like playful vs. serious. Theoretically, you could test microcopy with users on these dimensions and see which approach gets you closer to the tone you want to strike.
If this is for a customer-facing app, I think the tone you take needs to match the customer expectations and context, and probably defer to brand personality as well.
One more thing - slight tangent here, but I would wager that a playful approach to error messages is more memorable than a jargon-filled approach. That’s an assumption you could easily rule out with a 5-second A/B memory test, playful vs. serious. But my point is that bugs shouldn’t be there at all, let alone be conspicuous and memorable…