Just as it's easy to spin up comms on Twilio, it's getting easier by the day to spin up Twilio-esq infrastructure itself. They had first mover advantage, but it doesn't seem good enough (not taking into account their largest customers deciding to internalize the functionality to reduce costs).
There are plenty of switching costs. Porting numbers from one carrier to another with zero downtime, for example. Negotiating a contract with a new carrier. The new carrier may not support numbers, calls or SMS in some countries you are currently supporting. Testing deliverability and call quality across multiple carriers in multiple countries; you might discover that the new carrier routes messages/calls using unreliable carriers. The new carrier may not have good procedures for avoiding toll fraud. Sending SMS messages that contain Unicode might render like à on some phones; Twilio put a lot of time into figuring out how every carrier treats those on the wire and ensuring that messages get rendered properly. Fallback procedures may break.
If you want to host it yourself now you probably need a NOC, and to test binds, and to test the fallback protocols, and to figure out every edge case that carriers have with respect to certain numbers, messages or routes.
I agree that Twilio blazed the trail, but much of what you mentioned is a known quantity now and can be replicated with less effort.
You don't need to be as good as Twilio, just "good enough".
While working with one carrier is easy, working with 5, 10, or 100 is a horrible pain in the ass. In addition, you need a compelling reason to convince higher ups in your org to sink $texas-sized dollars into this.. long before you can send that first message.
Uber is a special case as they needed coverage in countries that Twilio didn't support. Further, they had a ridiculous pile of money. Since they had to stand up the architecture anyway, adding the "easy" countries made sense.