I'm not omniscient, but I can think of at least a few reasons from the top of my head:
* Hibernation doesn't work well on your hardware, but suspend does. This can mean that hibernate doesn't work at all, or that it fails randomly in 1 out of 10 attempts (my personal experience, some firmware is just lovely).
* You prefer fast wake-up time (or e.g. that you don't need to decrypt your hard drive again) to a longer hibernation resume and you know it won't be long before you're going to wake up the device (e.g. an office laptop, to be woken up each morning).
* You want to prevent people from inadvertently booting OS2 while OS1 is hibernated, because that can easily destroy filesystems (when they are mounted to both). A real world example is Linux+Windows installed on a desktop/laptop with a Windows partition mounted in Linux. If user1 suspends Linux (which later hibernates), a user2 starts the computer and boots into Windows, and then later anyone boots into Linux again (which resumes from hibernation), the Windows filesystem can easily get corrupted. This would not happen if the computer was always just suspended, but can easily happen if the system starts stealthily hibernating later (and you can even disable it).
Don't take me wrong, I think this behavior is great and is a much better default for a general audience. But you asked why would anyone want to configure it, and I believe there are solid use cases and their users shouldn't thrown under the bus. I have at least one colleague who said he really prefers standard suspend over suspend-then-hibernate. There will be users like this.