You choose this if you are going to be wanting to support multiple platforms with the same app / codebase. You want to deploy it on the web, you are probably going to be making a website application anyway, and you can kill two birds with one stone like this. You get the widest possible support across multiple device OS’s and manufacturers because they are all implementing HTML5 compliant browsers on their devices. The screen sizes will be different and you will have to take this into consideration, however most of your code will just work. You get the added benefit of being able to update your source files on your server and have them immediately deployed to all devices, there is no app approval process. Clearly, your app is not discoverable in the App Store, however it IS possible to give it an icon on the homescreen of devices like the iphone such that it looks exactly like a native app, even though it isn’t.
A native app is an app written to a specific platform like iOS or Android, where the app is written in the language used for development on that platform (Objective-C and Java in this case). The portability of the code to other platforms depends on how it was written (if portability was in the developer’s mind), but will always require some level of rewriting to use on another platform. When you write native, you get access to all the hardware features exposed by the native code APIs, which is typically most of the functionality of the device, definitely more than a web app. Apple push notifications is one example from your list that is an iOS specific feature which is not supported by a web app. It is “Native” because the code you write is essentially written for that platform, it is built for the native architecture of that device (implicitly implying that cross-platform support might be an area of concern, and it is).
You choose Native if you want to use the UI components from Apple’s proprietary UI libraries (the usability is better) and for better device hardware access. The UI experience is very likely what you are thinking of when you think of “iphone apps” and how you are used to them functioning. You choose it if you need hardware access to graphics for performance reasons (as with games) or need access to some other features that are proprietary to Apple and not supported in a browser sandbox, like Apple push notifications, in-app purchase or appropriate camera access. Your code is less portable but more performant, and more powerful and capable for the platform it is written on. Your app is discoverable in the app store and you can monetize your app by leveraging initial purchase price or in-app purchase, in addition to advertising.
A hybrid app is a web app that is deployed to a native platform like iPhone inside a native harness. This harness is usually little more than a browser view (to display the HTML5 content) and some other hooks to allow your web app to potentially access some more hardware features that are not available inside the browser sandbox. It improves code portability because if you want to port your app to another platform, you only need a native harness on that other platform to run it, the HTML5 content of the app is directly portable. These harnesses can be hand written, but can also be generated automatically by tools in the marketplace like the much lauded PhoneGap. These tools try and make a single point of contact for the developer, who can then turn around and push their app out to multiple platforms quickly by generating the harness and packages required to do so automatically. This sounds powerful, and it is, but clearly the PhoneGap people have a ton of configurations and hardware to support, and thus, the solutions do not always work the same across all devices, and in practice, testing and hacking of special cases will be required by the developer to get proper support if the app is anything more than a website in a browser control.