I wish I could tell you how many times I've seen a machine run out of disk space because logrotate had been failing since the last time someone pushed out a config, or a new log file appeared with a software upgrade. It's gotten to the point where I give /var/log its own disk partition now, and hunt down any logs in /opt and bind mount them into /var/log. Screw the logs, I want my system to keep running.
I am 1000% in favor of apps managing their own logs. Generic system agents can collect and ship arbitrary logs remotely for storage/processing.
If you have a standard cloud image and want it to use all the disk given to it, one big xfs partition is easier than a bunch of various little partitions for the sake of not filling the root partition. Hopefully everything log rotates well and you have disk full metrics/alarms when they don't. And the architecture should be if the node goes bad for any reason just replace it (with hysteresis so you don't kill all the zookeepers at once when new traffic and bad rotation/rentention fills the disks all at once)
Your "easier" has a lot of complicating qualifications. :)
I'd describe single-partition as "slightly simpler, but requiring additional support mitigations, and less effective at the primary job of keeping systems running".
I prefer:
One partition for / which is required to have an operable system for diagnosis of problems
One partition for /var which is expected to grow with limited predictability
One partition for the rest, which should be largely static depending on function, but sometimes surprises you regardless.
...
With elastic scaling compute nodes and centralized logging, most of these issues are subsumed into the enormous support infrastructure and can be ignored. But some applications don't map well to that environment.
I am 1000% in favor of apps managing their own logs. Generic system agents can collect and ship arbitrary logs remotely for storage/processing.