I was reading that page until I hit their preview of 1.2 work, and clicking through to the PR for CJK soft-wrap sort of confirmed all my fears about what a bad idea it is to try and write a text editor against a browser engine.
Just from skimming it a bit, to handle Korean, their developer decided that Korean characters have a special unique width from other writing systems and gets that width from the cached bounding rect of a particular char as run through the engine, and then that factors into their wrapping calculations. So now they have a function called getKoreanCharWidth and are basically implementing alphabet-specific text layout in a bad way on their side of the fence. It doesn't even work particularly well, but most importantly it's obviously not a generic solution, and duplicates what the browser engine already does much better by using proper shaping and layout engines.
On the flip side, it sounds like Atom is a really cool project if you don't really know what you're doing yet and want to learn from your mistakes. Reinventing the wheel and noting it hobbles is a good way to acquire experience, and it's not like the world relies on Atom. Perhaps it also creates positive pressure to improve the APIs they're writing against, even though it's sad that happens so indirectly then.