It seems to me there are two major issues.
Firstly, what about disaster? Although you have space now, what happens when the storage fills up? If the data storage fills its own volume, your data-driven processes stop - but your server runs on. You can get in, and fix things easily. If the data floods the OS volume, logging stops, the OS may stall, remote logins may become difficult, it's a mess.
Secondly, how do you recover from or avert disaster? If you decide you need more space on a separate data volume, pumping it up to a bigger one is easy. Enlarging the root volume is trickier, though not impossible; pain is lessened with a separate data volume. What if it's not disc space, but CPU/memory that's now inadequate? If you decide you need a bigger instance, migrating the data when it shares a root volume is time- and bandwidth-consuming. If it's on its own volume, you stop the first image, detach the volume, attach it to the new image, and your data's moved across (yes, you could do that with an old root volume, but then you have to do a bunch of cleanup - and cleaning up old device and proc files isn't always problem-free). Again, pain to come is lessened with a separate data volume.
By no means is it impossible to run with mixed OS and data; many people do it. But you minimise future pain - which is a goal of any professional sysadmin - by not so doing.