Many people use programs that bite off more than they can chew. I think this is the wrong way to try to make programs because there can be a lot of bugs in that code.
If you have a program like touch, the code only allows you to create a file, so the only bugs or exploits that could be used are with creating a file or potentially having an exploit that affects the filesystem itself. This scales big time.
I think the Unix philosophy of "write programs that do one thing and do it well", is amazing. Think about how the programs doas and sudo are very different.
Sudo tries to do everything, even if you might not personally need the functions, like making it so only people can sudo at some times.
Doas takes a more Unix-like approach, where it only allows a user to do something as a different user.
As of this writing, sudo has 170 CVE, while doas has only 2 CVE.
The use of compilation flags for programs can help with the vulnerability aspect. It can make it so that the client can pick what they are going to do at compilation time and not at run time. This will make it so that you only get exactly what you want.
This can be like Suckless, where most of the programs are very barebones but you add patches that you want. This makes it so that if there is an exploit with tabs but you don't have tabs installed, you can't even be affected by the exploit.
With programs that try and do too much, it's not only a security risk; it can cost. If you make a program that does more than it can do, that means that it is going to take more time to run your program. More time means more CPU time. More CPU time means more electricity. I think you know where I am going with this.
I think that if you add up all your programs and how much time you spend waiting for things to happen because they try to do more than what you want, it would easily add up to months of your life.
Think about when you want to read a blog. Do you want to wait 10 seconds as all the javascript, ads, and pop-ups render? That equals real time and money that both the server and the client have to spend.
I think the final and most important reason to have minimal programs is that they will be easier to maintain and for others to contribute. If it's easier to maintain, it'll be much easier to fix if a vulnerability or bug arises. If your program is easy for others to contribute to, then if people want, they can make their own forks with all of their changes. If you ever need to take a break from the project, others can easily take over and understand the code in no time.
"An idiot admires complexity, a genius admires simplicity."
- Terry Davis, Creator of Temple OS