If adding the ARIA role fixes the problem, then it's not the fault of screen readers: it's browsers not exposing the semantics properly (unless explicitly instructed to). Please don't assign blame to the "obvious" target unless you actually know who's at fault.
If the screen reader were at fault, then explicitly specifying the implicit role (something that should be a no-op) would not fix the problem. It's the responsibility of web browsers to implement and expose implicit ARIA roles (see https://www.w3.org/TR/html-aam-1.0/#mapping-html-to-accessib...). Screen readers do not (in general) speak HTML, just like computer monitors do not (in general) speak CSS.
If that were true, no screen readers would work, which is not the case.
Have you ever used a screen reader? A lot of their failure modes are exactly as you'd expect from the model I've described: look at, for example, the differences in how definition lists are exposed to Windows Narrator between Firefox, Chrome, Edge, and Edge-in-IE-mode.
You’re right, some screen readers work better with specific browsers. The article doesn’t mention anything about that, though.
The output tag has an implicit aria-role=”status”. This is 100% on the particular screen reader(s) that don’t support it.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...