"this is what SOAP and Web Services APIs were promising years ago. The reality was rather different: you could end up writing a whole bunch of glue and data transformations to pull data out of X and push it into Y"
My experiences exactly. Spending days writing XML transformations between one schema and another and making new web services in the internal house style just to call external web services, so that the internal applications used the correct style (I was made to do it this by the architect by the way , so don't assume I was responsible for this nonsense). Pretty much everyone is going to go for this wrapper / interface layer approach I would presume. Then come all the availabilty problems of multiply located services. For this to really work, every service needs to implement a simple "heartbeat" function to check that it's still alive and reachable, so a simple webpage can be put together for the sysadmins that lets them see the status of every component part easily and rapidly determine which service is at fault if there are problems. Then the usual round of phone calls / emails / shouting and swearing / recriminations can begin. But most people probably won't bother implementing this, so it'll scupper chances of being any more popular than SOAP / REST services currently are.
I am in total agreement too with all others here who have posted that the "this will eliminate the need for trained and experienced devs cos idiot code monkeys will be able to do it all" claim is making its' current apperance, shortly before deeper consideration tucks it away for another couple of years, until someone invents the next version of this square wheel.