That said, a lot of these sorts of systems are notorious for being pretty awful, too. Yes, there are many millions of man-hours poured into them, but that doesn't mean they're good; those man-hours could very well be spent on trying to implement every bell and whistle under the sun while entirely neglecting bug fixes, for example (and - speaking from experience - that is a disturbingly-common example). Also, having a bad UX can (and often is) a fatal problem for such a system (sometimes even in a tragically-literal sense, e.g. with EMR/EHR systems and other medical software); the whole point of business software is to optimize user productivity, so the last thing you want is to make the user's life harder.
So yeah, tradeoffs. If you're gonna fall into the DIY trap, the key would be to not try to replace the entire ERP or entire WMS in one go, but rather to build smaller tools that optimize specific business processes, and make sure those tools stay small and maintainable; any expansion of features should happen through interoperability between tools rather than trying to build a giant bloated tool. If you're thinking "wow, that sounds like the Unix philosophy" and/or "wow, that sounds like microservices", that thought ain't exactly a coincidence.
The biggest thing that people who try to roll their own fail on is this right here.
It is scary how many systems cannot be audited this way because the engineers and business owners had no understanding of basic accounting concepts like double entry book keeping.
Systems that are not designed to be easy to financially audit are either going to overbill or underbill customers. It isn’t a matter of if, but when...
For example: let's say you have a warehouse management system, which tracks inventory movements in a warehouse / fulfillment center that ships, say, toothbrushes to customers. Multiple customers call in with complaints about getting blue toothbrushes when they ordered red toothbrushes. Seeing as how this is clearly not an isolated incident (multiple people are upset about not getting the right toothbrush!), it's up to you to find out where in the whole lifecycle of that toothbrush in your warehouse - all the way from when it was received to when it was shipped - that error might be happening. If your warehouse management system is completely auditable, then you'll be able query the transaction log (given perhaps the affected order and item numbers) to work backwards to investigate where the fault occurred, be it in shipping, picking, replenishment, receiving, the vendor, or what have you.
The "incumbent" off-the-shelf ERP and WMS vendors tend to support this sort of comprehensive audit trail much more thoroughly than those writing new ones (whether as an in-house project or as a startup attempting to disrupt the space), simply because those incumbents have already had their hard-earned lessons on why literally every transaction must be thoroughly logged (whereas the newcomers and DIYers typically have not, or are in the process of learning as they encounter more and more situations where that audit trail is necessary).
Any system, e.g. SAP, that has a proofen track record in that, that is SOX compliant, is a huge benefit in that regard. Also for the company itself, IMHO, as the company is forced to work in compliant ways that just make life a lot easier.