When there are so many layers between you and "the metal", it's just a matter of time before one of those layers creates a road block. You can get around these road blocks in at least two ways: 1. install native code and get to the metal, or 2. use less efficient techniques to get around the block.
Taking route 1 means you can't claim "cross platform browser app" any more. Taking route 2 leads to slow code. It looks like MS chose route 2 and decided to use a frame-by-frame animation instead of using the obvious "timer and XOR" that's been used since the dark ages. I'm guessing that timers and/or XOR aren't available in whatever API was exposed by the browser environment.
After that, it becomes less clear why it's so slow. Even though rendering a cursor frame-by-frame is still less efficient, it shouldn't be *that* inefficient. As others have pointed out, you have a dirty rectangle and an update 60 times per second. Maybe the underlying API is re-rendering the entire screen.
And that's how you get to 13% CPU to blink a cursor, and a lot of other things. That's why web apps keep sucking. It's a problem that can, in theory, be solved; but it won't be solved because it's a lot of work across many different organizations, each with different objectives all trying to hit a moving target of changing architectures and standards.