YtsClient and YtsRoster have a 1:1 relationship. The public API would be simpler if YtsRoster was an implementation detail, and all of its public API moved to YtsClient.
To provide some perspective, I think the original idea was that if an app only provides services, you just need the YtsClient. If you want to discover and use services, you use the roster.
The plans for refactoring were that the Roster was instantiated by the application only when needed, and registered with the Client, so it could be kept up to date.