> What does ‘minimal’ even mean though?

It doesn't include the batteries.

The batteries - extra features - weight you down if you don't need them. So you'd better be able to avoid them. Large projects can be hard to audit to remove things which could be nice and often useful - but just not in your case.

Smaller projects have an advantage that you can easier understand them and decide what you need to add and, crucially, how to add that better, from your personal viewpoint. It's really hard to have nice, tiny, composable building blocks, so we have rather few attempts at that. Actually, a big part of programmer's education is teaching him how to properly write something which is well known, just have many small variations which depend on both requirements and some preferences. With a smaller project you can see those choices easier - and have better chance to correct them the way you need.

> The minimal/zero-dep solution will have have bugs that have already been fixed or avoided by battle-tested libraries

Maybe. Maybe not - you need to have all branches of execution checked, and with all possible input data combinations - and then all problems to get noticed and, crucially, corrected. Some problems, like unnecessary delays, can avoid e.g. representation in the logs.

On the other hand, with smaller projects you have less moving parts and better visibility where, and how, things could go wrong. If you want ultimate reliability with proofs, you'll find it easier going with smaller projects.

So, as they say, there are programs so simple they're obviously correct and so complex it's not obvious which errors they have.

> Code is code - either you pull it down as a dependency or you write it yourself, it all executes the same in the end.

This looks like an oversimplification sometimes. You surely can solve the same problem in programming in different ways. An important part could be unstated assumptions you relied on when you wrote your code - and sometimes it's really important to understand those assumptions, or the code could strangely misbehave. "All executes the same" could literally be not true - some testing may suggest that, but more expensive testing, which is often not done, could show that for some unusual combinations the behavior is different.

How do you know it's the same?

I'm reading it as "minimal in scope". Scope creep tends to be a given for established/battle-tested libraries, and I'd argue that over time scope creep could counteract security benefits of being battle-tested.

Note that I'm not basing this on data, just on my intuition that a lot of major security bugs seem to be related to obscure/infrequently used functionality.

This is definitely true. The more complex the library is, the more chance for a vulnerability to happen. And combining 2 independent low level vulnerabilities may end up being a critical vulnerability.

The same may happen in your project, but if you use simple(r) dependencies, it's less likely.