I've done both over the years.
I definitely lean towards subdomains these days because it's practically easier - I don't necessarily have the subdomains on the same server or same hosting setup depending on exactly what I'm doing, e.g. if I have a WordPress marketing site in front of a more complex booking app, I'm *definitely* putting those on separate subdomains, especially because WordPress plays hell with htaccess files, and when I'm doing complex booking/ecommerce stuff, I'm using Laravel which has specific rules about putting files in different places.
For self-contained apps subdirectories can be fine but more and more software is doing the 'expose only the web-facing bit of the app in the public_html directory' and keep the rest outside so subdomains are (much) easier to get that going.
But it's possible to do some really gnarly things if you have complete control over the server stack, for example one site I maintained for a while had a Python based front page/login which controlled which tiles you saw when you logged in, and each of the tiles was its own PHP application 'in a subfolder'. All tied together through SSO so you log into the portal, then each of the sub apps would work as if you'd logged in, but it was... pretty rad to build. Lots of magic involved with having a webserver in front of the webserver - the Python stuff ran on Python/gunicorn in one container, each of the PHP apps on Apache/PHP in their own separate containers, and a single front container with nginx to broker all the connections and some fancy wiring in AWS land to make any of it work. I'd never do it again if I had the choice, I'd totally prefer to use subdomains but it *is* possible if you have the time and inclination.