1. It is easy to run your own services. You should be investing in internal developer tooling that makes this easy, and in fact that developer tooling should sit in front of any vendor solution you ever buy so that the way it integrates with your alerting, monitoring, data exporting, etc., is completely standardized to be uniform with service delivery in any other system in the org.
2. and 3. You do need complete control over what the application does because it absolutely always is unique and special on a per-use-case basis every time. A good example is search. Anyone who thinks search is a commodity service you can just throw ElasticSearch or Algolia in front of is sorely mistaken and dangerously naive. Every different search use case is going to have different success criteria, different data privacy concerns, different timeliness and freshness concerns, etc. and you need business software to control these elements in ways that fit into standard internal product management and QA procedures.
4. Vendor lock-in is a critical problem. If you choose GCP vs AWS, you are defining culture and you are defining experimentation and exploration that you cannot do. You’re essentially cleaving away many future possibilities from even being testable. It’s much worse than just having a crufty old system to maintain, it’s about brittleness and lack of ability to appropriately empower engineers to consider whatever part of the solution space they decide is needed. Companies that “get it” will prioritize “ease of swapping” so that you can constantly improve and leverage autonomy without needless parochial constraints on what can be considered. Thinking, “yeah but just buying it solved our problem today” is such a death knell of weak leadership who cannot fathom strategy or how to leverage real solution ideation from their staff.