The prpl high-level API is there to help battle market fragmentation.
From an operator’s point of view, he has to deal with multiple gateways: new generations of devices, different broadband technologies. Becomes more complicated if you are active in different countries (where some differentiation between the countries is needed).
ISPs want to add customisations (e.g. web UI), and this has to be redone for every gateway. So the focus shifts away from developing new services towards just integration of different gateways.
The goal of the prpl high-level API is to have seamless deployment of ISP customisations on multiple gateways. It brings down device time-to-market. It allows to focus on differentiating features, and thus allows generating new service revenue.
A router has a base system (with e.g. firewall config, wifi control daemon), with an IPC bus on top, and the web UI on top of that. The high-level API defines a number of micro-services. It is a specification (JSON Schema) that is independent of the IPC bus.
But the high-level API is not sufficient - the service still depends on the IPC bus. Therefore, a prplBus component is introduced that abstracts the underlying IPC bus. In addition to abstraction of IPC, it also brokers access, as a containerisation mechanism. Although some IPC buses do have ACL mechanisms, these are not interoperable.
A final step is to add a remote bus adapter that allows access by e.g. a remote app. Since the remote adapter offers the standardised prpl API, there is no need to write the app specific for the device.
Collaboration is really key to be able to have the time for actual innovation and differentiation. Different code does not mean that it is differentiated.
Why not use TR-181 instead of inventing something new? This was in fact considered, many options were compared and in the end (after voting) it was decided to develop something new. TR-181 is built mainly for remote management; real-time mechanisms are not there.