If I want to add a piece of data and a visualization of that data the UI and the data store should be in the same service, no exceptions?

You're saying that a desire for when something gets worked on should trump any other design decision? "Want at the same time" informs separation of concerns?

You make services in an vacuum without considering the stakeholder/consumer of your service? You've never planned for a service in your org you consume to gain functionality because doing so would mean you should implement that functionality yourself in a service you own?

Teams that call themselves "platforms" are very often tempted to operate in a mode where they add a lot of one-off endpoints tailored to the specific use cases of particular callers. This skips the whole economic value of "platform" and makes them consultancies instead. My company has this problem in a big way, there are CTO-level efforts towards reusable abstractions and generic extension points instead of all this deep cross-team cross-service coupling. It is frequently the way I can add the most value in a design review: help the team come up with abstractions based on their domain model that are sufficient for their callers, instead of building to the letter of current callers' requirements (and signing themselves up to keep doing that for each new caller).

"How often will we need to change this and what will that be like?" is usually my top design consideration after "will it work?" So yes on that one.