There's no problem in embed well audited dependencies, noone would be better secure than use directly libsecp256k1 (maybe the system overall could be fragile in case of a vulnerability discovered, but for your software is the best option). The problem is take shortcuts to add features instead of build slowly (and sometimes simply dont build at all) less necessary things. Some of these shortcuts consist in embed to much and low quality dependencies, or use frameworks and make this shortcuts squared.
The article specifically states that it's a good idea to reuse cryptographic libraries that have been well tested. I think it's even fine to initially take on the technical debt of a dependency that lets you get real world experience with an idea faster, as long as you accept the possibility that this dependency probably requires more scrutiny if you intend to keep on using it. It's complicated and definitely not a black and white case that you should do something yourself. Both ways can go horribly wrong.