I agree, unless someone can point to anything Apple has ripped out or deactivated in WebKit. Apple seems to have been pretty open with Mobile Safari.
The most closed thing I can think of is when they only enabled their faster JS engine for the browser itself and not for apps. The next major release changed that, and it is not related to WebKit itself.
Apple has restricted some stuff in WebKit but I don't think anyone would argue that they did so to weaken it. For example you can't (or at least couldn't in the past) use position:fixed in Mobile Safari, and overflow:scroll was relegated to a two finger scroll that no one really knew about and is/was a little intuitive (I think they've fixed this with iOS5 though).
Nitro is enabled in iOS for web apps added to the home screen, but not UIWebViews (aka, PhoneGap). While I don't think it's actively sinister, it doesn't seem like they're going out of their way to correct it, either.
The problem is that they can't allow programs to execute parts of the memory as instructions. This is needed for efficient JITs like the one in Nitro.
Apple is actively (Frequent commits) working on fixing this problem. The project is called Webkit2, and features a Javascript interpreter that runs in a separate process, and thus is able to safely execute Javascript on iOS. This model, btw., is inspired by the multi-process architecture found in other major browsers.
The most closed thing I can think of is when they only enabled their faster JS engine for the browser itself and not for apps. The next major release changed that, and it is not related to WebKit itself.