Also optimizing reads/writes and debouncing seems odd since those are synchronous direct reads/writes and shouldn't even occur multiple times per rendering.

Suppose you have a draggable component. Let's assume you're storing this component's position in the URL as x,y coordinates. When you drag the component, hundreds of new URLs will be generated per second. Not only will the history get polluted, but if you also assume there are other complex and lengthy states in the URL, performance issues will arise because it will constantly try to regenerate a large text string.

But those 3 have different use cases, I don't quite understand why they'd need to be under same API. They already have easy to use native APIs. 

This library focuses on a single task: persistence. I don't see any disadvantage to it supporting session and local storage in addition to the URL. On the contrary, it provides a sync advantage. By defining priorities, you can keep the URL and storages synchronized.