Three different use cases for status notifications.
I'll give you my experience with using these commands and where they are useful.
Logging event trunk-status--this command is particularly useful for tracking security vulnerabilities as well as trunk mismatches when you're relying on DTP for trunk negotiation.
Say you have a trunk uplink on a switch that links to a distribution switch. This trunk carries traffic for multiple VLANs (thus the very definition of a trunk).
Lets say the other side of the link on the distribution switch is for some reason changed from a trunking state (switchport mode trunk, or switchport mode dynamic desirable/auto) to a non-trunking state (switchport mode access). If the uplink on your access layer switch is not hard-coded for trunk-mode (switchport mode trunk and/or switchport nonegotiate), then your uplink interface can potentially be changed from a trunk port to an access port and only carry traffic for a single VLAN. This would leave other clients on the access switch VLANs stranded from the rest of the network. This logging mechanism would let you know that the switchport is no longer an operational trunk, even though the link status would still be up.
Of course, as a best practice, you should never rely on DTP to form trunk links, especially on uplinks.
The second use is for security--if you have an interface that you KNOW should never become a trunk interface (i.e. an access port where clients connect), and for whatever reason the interface becomes a trunk link (due to a compromised switch or an over-reliance on DTP), you could potentially expose VLANs that users should never have access to. This logging mechanism would let you know if that happens.
Logging event link-status--this one is simple--it logs whether the interface is up/down or changes. One thing I find this useful for is on particularly important interfaces--uplink interfaces, routing adjacency interfaces, server interfaces, etc. Use this on any port when you want to absolutely know if it goes down.
Logging event bundle-status--this one is fairly simple as well--it logs whether there is a change in the port-channel. This could be triggered by a member interface leaving or joining. One reason you would want to use this is for guaranteed bandwidth and configuration consistency.
Sometimes port-channel members leave a channel-group because the configuration is changed on one member and not on the other, likely by mistake. This could catch an error like that and cue you on where to look into the issue. As for bandwidth, obviously you don't want to believe you have 20Gbps or 2Gbps on your uplink, then find out that you actually have half (or whatever portion) of that bandwidth missing because a member has left the port-channel. Both situations can be avoided by monitoring the status of your bundle (or port-channel).
