Ok, there's quite a lot to unpack here.
First thigs first, this solution will not pass any kind of WCAG test, its transparency kills the main reason it is there: to be easily discoverable.
Offset magnifier assumes that you cover the row you would like to navigate with your controlling finger, hence the offset. For that
same reason there's actually one cursor visible on the screen
during that interaction. So the point of making the magnifier inline
defeats the purpose of the magnifier.
Pressing harder to select word while draging a cursor is as ambigious and non-discrete as it can get with mobile touchscreens, seriously. Even with a dedicated tech tailored to that specific purpose (force touch on iPhones) it didn't take off at all, discoverability has been very poor.
Yeah, and then put some pretty intervening features (like "cut" and "undo") on top of that noisy gesture! That won't backfire at all is any of the "less than ideal" environmental situations, I'm sure.
Now for the statements of the author:
"First, as too many people mistakenly see text editing as “done”, there is little appetite to fix it." - in other words, there're not many people that consider this a problem at all
"Second, users have been trained to cope with this error-prone approach for well over a decade." - people do get used to bad things, but if the problem is significant and the solution is elegant, then the adoption rate is pretty substantial. It didn't take long for all the mobile UX to switch to acceleration based scrolling from the scrollbar based, even though people has been using scrollbars for a thousand years. Same thing with a mouse wheel.
And finally, the solution (that has been already implemented):
Move the cursor controls to the place where text input happens - the keyboard. It's already open and you can easily engage a dedicated mode for these types of interactions. But android and iOs keyboards already do that.