A legitimate example of multiple containers in a POD is hinted at in the official docs:
These co-located containers might form a single cohesive unit of
service–one container serving files from a shared volume to the
public, while a separate “sidecar” container refreshes or updates
So you can use an nginx container that serves content out of the pod disk and another container that runs “git pull” in a loop with a short pause to refresh the html content on the pod disk.
Of course people would typically build an image containing the latest html using “FROM nginx” at the top of the dockerfile so they wouldn’t normally do things the way I described.
So the real answer is that most folks can and should avoid running multiple containers in a pod. If your starting from scratch building a typical new system you can keep things clean.
Yet more and more people are moving legacy workloads onto kubernetes. Then you don’t have a choice about the actual application architecture. In which case you may find you need to run two or more processes that share resources wiring a pod. That’s a total anti-pattern for modern “share nothing” microservices but legacy code doesn’t follow modern best practices.