It depends.
In certain stacks that can be relatively "self-contained", like Java, where you just need a version of JDK, it can be easier to just install it on the system and run/debug/develop your application locally, even if you can deliver it inside of containers. Why? Because remote debugging can be a bit of a bother to setup (in any stack) and sometimes the IDE integration works better without containers, provided that you actually embrace coupling your development process to the IDE.
In other stacks that would be more complicated to setup, like PHP, it can be better to run even your local environment inside of a container, bind mounting any of the files that you need into it and working that way. If done correctly (e.g. you don't suffer too much because of file permissions, should your host OS use NTFS), it can be similarly easy to the Java example, though remote debugging setup will be a must.
As for other complicated pieces of software, like databases (MySQL/MariaDB, PostgreSQL and so on) or object storage (MinIO/Zenko, or another solution that's similar to S3), key-value stores (for example, Redis or memcached and so on), it's almost always going to be better to run them in containers.
It's not so cut and dry, though, because all of the software that you don't need to develop/debug but just need running locally can also run in containers with no issues. The problems start when you try doing something fancy - like wanting to run the applications you're developing locally with Skaffold and rebuilding them on code changes, which in practice will be slower and more resource intensive than doing that natively on the system.
Of course, what's true for me and my projects, might not be true for someone else.