it would be interesting if they elaborate on those...
Of course, it'll be hard for you to tell a convincing story because (AFAIK) Apple hasn't even commented on IndexedDB. Strange, for such a well-established open standard. Even MS has supported it for years!
As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against.
[EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.
This reeks of the same logic that caused them to disable HTML file upload buttons (there's "no" filesystem -- which is apparently why you can't even browse for photos and uploads until recent IOS).
This is what drove "there's an app for that" for so many years: Apple's systematic limiting of web apps into a severely curtailed walled garden so that the app store would -- in fact, could -- be the only source for real applications.
"Web Apps aren't as performant as native" is a direct result of such strategies.
In other words, those strategies WORKED. As with all anti-competitive practices, they will keep doing their job for a while, until something new and better (or at least workable) comes along.
Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.
It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.