I get the sentiment, but it really depends: For some services, it's very true. For other services, careful problem analysis will show that you only need one or two features from the full package, which then can be replaced by a very small shell script.
Last month, I needed to add a periodic job to a simple Rails app to snapshot some data and send it to another system. I discussed the design with a colleague, a Rails expert, who went into the pros and cons of various worker-queue configurations. In the end, I added a hidden API call, and deployed a shell script along the lines of
while true; do
curl https://rails.app/do/the/thing
sleep 3600
done
The actual version is slightly larger because of error checking etc., but that's the gist. So that's one example of replacing (or rather: avoiding) a distributed system (an asynchronous job queue) with a small shell script.
I don't mean to say that shell scripts always can replace more complex systems, but sometimes they're enough.
Except you're gonna need between 10 and 100 people to recreate the service in-house, not just one.
Trying to re-do something from scratch in-house is always more expensive than just buying the product.