The problem is, publishing an API is making a promise: you're promising that it's safe to build on the API because it will be maintained into the future and will avoid breaking compatibility.
These promises can be expensive to maintain, restrict changes and if you break the promise, it's worse than if you had not made the promise in the first place.
Imagine Peloton did open their API and some third-party did create Apple Watch support. Every time they do a software update or release a new machine, they may break something in the third-party integration, which leaves the third-party to scramble to fix the issue. To mitigate this, Peloton would have to do communicate changes and provide beta releases -- that is, start and run a developer relations program.
This is not small potatoes. Opening an API that will actually be useful is a big, on-going deal.
Now also consider the third-party who has created the integration. They are making a promise of their own to their end-users, especially if they are charging or manage user data. Yet they are highly dependent on Peloton's promise (API) to be able to fulfill their promise to their end-users. It's a precarious network of dependencies that will break when the interests or priorities of any the parties diverge (and they will diverge over time -- they are separate parties with different concerns).
Keep in mind that if Peloton has decided they no longer want to maintain Apple Watch support, they could just as easily (and for the same reason) decide not to maintain the API that would make it possible for a third-party to provide that support. In fact, I think Peloton would be a lot more OK with cutting off a third-party developer -- who is not their customer -- than in taking features from their customers directly as they did in this case.