If you paid attention to the latest releases of both TFS and VSTS you can see that the main path where they are diverging is on Process Template Customisation.
And hey presto! I was asked why, and why is it that different from the usual TFS experience. So here is my opinion on the matter 
Historically, *no* customisations were allowed for Team Projects hosted on the service. The reason behind this was very pragmatic: being a service, the provider must ensure that any upgrade are not going to break the system for its users, and that includes customisations as well.
Enabling the typical task witadmin.exe can do means they can’t ensure that “the trick you used with Global Lists to show something on a certain field” is going to continue working, with no changes, for each upgrade the service receives without testing it. And of course, the service provider neither can test users’ customisations nor rely on users to test their own customisations according to the service release schedule. It wouldn’t work, and it would cause unnecessary churn and technical debt.
Normally – and this applies to Team Foundation Server as well – you would test your customisations in a sandbox or a test environment. With your own on-premise product you can duplicate the instance (especially with the new pre-production upgrade feature) and start messing around with it. It makes total sense, because hardware is cheap as chips these days and you (or the admins) are responsible for the uptime and availability of the server.
But you can’t have it and you can’t do it on the service, there is no test environment, a service is live by definition! Even with DevOps properly in place there is no way of providing this with the appropriate safeguards.
There is a major difference between providing APIs to extend specific components of your service (usually with a limited scope) and providing a way to easily customise the overall user experience. This difference sometimes is overlooked (unfortunately) when in full-swing with the DevOps infatuation: introducing breaking changes (because you will, everybody does, at some point) on a large portion of the user experience that non-technical users will face is something to are going to regret, because non-technical users are usually more vocal and reactive to UX changes.
UX changes aren’t like custom release task using the VSTS APIs “somehow”, they are all about consistency in the overall experience a user has, and it is critical to understand what is going to happen the second you break something you can see. Can you imagine the mayhem when a non-technical user, who heavily relies on that customisation, is going to get an error and his critical feature isn’t there anymore?It was the right decision, because the team was missing a way of funneling the customisations in a sanitised and reliable way.
But now they have! And they are doing a great job at enabling these Process Customisation scenarios – usually a big blocker in Enterprise situations.