I believe the hibernate and stop mode wakeup times are roughly the same. There is a slight difference in behavior and current draw while they are "reset/off" in the two modes, but once the chip goes to startup they behave pretty much the same.
Lower advertising intervals and deep-sleep will get you the most power saving while still having the device's BLE chip running. Using hibernate or Stop will save exponentially more power, but both of those require an external button press/IO toggle to start the chip going again.
Unless you want the increased power saving of the hibernate/stop modes over the deep-sleep modes in exchange for having to push a button to manually reset the device, then deep-sleep is the most common mode for saving power while still running the device (with deep-sleep you can still get years of power off of a coin-cell with proper application). Here is the app note on power modes and saving battery life: AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications
The latency and Connection Supervision are described in the BLE component datasheet, but Slave Latency understanding - Bluetooth® low energy Forum - Bluetooth® low energy - TI E2E Community and Connection parameters - Introduction to mbed BLE explain why you would modify/use the slave latency, and the connection supervision timeout is essentially an overall connection timeout for the devices not having communication for x ms of time.
If either the slave latency of the supervision timeout fail, then the connection will end. There would be no effective difference in behavior for one ending versus the other ending. But, the central device doesn't have to end the connection after the supervision timeout (slave latency either I think), but can instead use it as a notification of the remote device being missing/unresponsive.
If you don't need a feature/functionality, you don't have to use it 
Googling "BLE" followed by the keyword search terms generally yield good results, as most of the BLE features/functions are extremely standardized across the industry. Right-clicking the BLE component and opening the datasheet/api documentation will also give you a large library of information on BLE operation (I recommend using the search functions to find specifics you are looking for)
The peripheral can only suggest connection settings, as the central is the device in charge of the connection overall, thus it can veto/ignore/use any settings that the peripheral suggests at it's own free will.
PS: I do agree that the documentation is had to read/find what you need to know in order to learn BLE, but if you already know BLE, learning how the Cypress chip is different from other chips is relatively simple. I recommend BLE tutorials/videos/getting started first, as the documentation is aimed at knowledgeable developers more so than new developers.
I believe the hibernate and stop mode wakeup times are roughly the same. There is a slight difference in behavior and current draw while they are "reset/off" in the two modes, but once the chip goes to startup they behave pretty much the same.
Lower advertising intervals and deep-sleep will get you the most power saving while still having the device's BLE chip running. Using hibernate or Stop will save exponentially more power, but both of those require an external button press/IO toggle to start the chip going again.
Unless you want the increased power saving of the hibernate/stop modes over the deep-sleep modes in exchange for having to push a button to manually reset the device, then deep-sleep is the most common mode for saving power while still running the device (with deep-sleep you can still get years of power off of a coin-cell with proper application). Here is the app note on power modes and saving battery life: AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications
The latency and Connection Supervision are described in the BLE component datasheet, but Slave Latency understanding - Bluetooth® low energy Forum - Bluetooth® low energy - TI E2E Community and Connection parameters - Introduction to mbed BLE explain why you would modify/use the slave latency, and the connection supervision timeout is essentially an overall connection timeout for the devices not having communication for x ms of time.
If either the slave latency of the supervision timeout fail, then the connection will end. There would be no effective difference in behavior for one ending versus the other ending. But, the central device doesn't have to end the connection after the supervision timeout (slave latency either I think), but can instead use it as a notification of the remote device being missing/unresponsive.
If you don't need a feature/functionality, you don't have to use it
Googling "BLE" followed by the keyword search terms generally yield good results, as most of the BLE features/functions are extremely standardized across the industry. Right-clicking the BLE component and opening the datasheet/api documentation will also give you a large library of information on BLE operation (I recommend using the search functions to find specifics you are looking for)
The peripheral can only suggest connection settings, as the central is the device in charge of the connection overall, thus it can veto/ignore/use any settings that the peripheral suggests at it's own free will.
PS: I do agree that the documentation is had to read/find what you need to know in order to learn BLE, but if you already know BLE, learning how the Cypress chip is different from other chips is relatively simple. I recommend BLE tutorials/videos/getting started first, as the documentation is aimed at knowledgeable developers more so than new developers.