If you care at all about users who depend on screen-reader software, don't do this.
Edit: actually, the author addresses in a follow-up post [0] why it shouldn't matter. I'm no expert on the area, though.
[0]: https://www.johndcook.com/blog/2021/07/19/removing-unicode-f...
I had Safari/VoiceOver speak this tweet [0] (no offense to the author, it was just the first one in my feed that had this style of character in it). Every letter is some form of "Mathematical bold script capital s"
In that particular tweet, not only does it not read the word, but the "i" character is "Mathematical bold script small 1"
[0] https://twitter.com/kiwapebretech/status/1420613820876271617
I don't think it's dismissive at all (let alone extremely) to say "this might cause a problem [and by extension, if this is important, do more research], but it shouldn't." It's pointing out an area where screen readers fall short unnecessarily.
Should the software be able to detect context? Sure. But that's not where we are today and to withhold content from people because their software hasn't gotten that far just seems wrong.
It's an interesting exercise in seeing what we can do with various Unicode characters, for sure. The 'disclaimers' presented could be worded a bit more strongly, as in "This will as of 2021 cause problems for people using screenreaders, so it's not recommended to use it."
The real issue is that there’s a general use case for basic formatting of real prose, and perhaps unicode should accommodate that. But expecting screen readers to understand these kinds of workarounds is unrealistic, and expecting it despite knowing it isn’t supported is user hostile.
Pointing the blame at the screen reader software absolves the decision maker for a choice that they themselves control.
It's also really handwavy to say that in context screen readers should know to announce something different than the actual characters being used. What if I want to tweet an actual math formula, for example? How can that be solved for?
It's a hack, and it doesn't work in screenreaders because hacks are often not robust when context changes, otherwise they wouldn't be hacks, they'd just be "the way".