How is indexedDB conceptually different from HTML5 local storage?

IndexedDB is not a key-value store in the same way that Local Storage is. Local storage just stores strings, so to put an object in local storage the usual approach is to JSON.stringify it:

myObject = {a: 1, b: 2, c: 3};
localStorage.setItem("uniq", JSON.stringify(myObject));

This is fine for finding the object with key uniq, but the only way to get the properties of myObject back out of local storage is to JSON.parse the object and examine it:

var myStorageObject = JSON.parse(localStorage.getItem("uniq"));
window.alert(myStorageObject.b);

This is fine if you only have one, or a few objects, in local storage. But imagine you have a thousand objects, all of which have a property b, and you want to do something just with those ones where b==2. With local storage you'll have to loop through the entire store and check b on each item, which is a lot of wasted processing.

With IndexedDB you can store stuff other than strings in the value: "This includes simple types such as DOMString and Date as well as Object and Array instances." Not only that, but you can create indexes on properties of the objects that you stored in the value. So with IndexedDb you can put those same thousand objects in it but create an index on the b property and use that to just retrieve the objects where b==2 without the overhead of scanning every object in the store.

At least that's the idea. The IndexedDB API isn't very intuitive.

They appear to run in the same thread as the async calls were made. How will this not block the UI?

Asynchronous is not the same thing as multi-threaded, JavaScript, as a rule, is not multi-threaded. Any heavy processing you do in JS will block the UI, if you want to minimize blocking the UI try Web Workers.

indexedDB allows a larger store. Why not increase the size of the HTML5 store?

Because, without proper indexing, it would get increasingly slower the larger it got.