The synchronousness means the whole DOM will block; blocking anything else would be an implementation bug, however that is not what Taras's post describes.
Blocking the DOM is bad. JS is designed as an evented language (the insight that led to node.js), which means it can't accept primitives that stall its main loop; breaking that assumption would add a lot of complexity to code that never uses localStorage.
It was? How do you explain alert and confirm, two of the first uses of JS? I don't think we need to add religion to JS. Node.js is evented because that works best for it. In my JavaScript thread if I want to wait for the localstorage get, so be it. This is isolated to my thread, breaking nothing.
However my point was that the claim of the scope of the problem are overblown. If a given implementation loads one massive store for localStorage, that's a problem with the implementation, not localStorage. The linked article worst cases on the back of a bad, lazy implementation decision.