@edgework: It's mostly about minimizing end user impact when API changes occur. There's two real categories here:
1.) A bug in the app itself often due to assumptions. In this case by testing against a beta endpoint the app author can fix the bug before their users are impacted by it. This is more impactful when the upcoming changes are fairly big.
2.) A regression in the API. In this case it gives the opportunity to provide feedback to you guys earlier and reduce impact.
During the seaserpent beta I found a bunch of bugs in my app that fell into #1 and quite a few that fell into #2. Both ended up getting fixed before the rollout because of the beta endpoint and my end users saw no real impact. If the changes had just been deployed I probably would have had at least a week's worth of disruptions while I worked through issues. Like I said before I don't suspect what you asked about is really impactful this is more of a general suggestion. I know that having a beta endpoint to test against is more work for the engineering teams so I can appreciate that it may or may not be the right thing here.