Yes. Exactly.
It would be hard enough to introduce a full fledged editor created internally by Kemper. The work flow can be controlled, and only the series of commands that the editor actually makes need to be validated.
Creating a 3rd party API (application programming interface) opens Kemper up to a nearly infinite number of work flows and command sequences that would result in many many many failure paths.
I'll say this: the API "endpoints" (for lack of a better word) they've had in place since way back in FW3 seem to be VERY comprehensive. You're essentially doing call/response style NPRN integer & null-terminated string messages wrapped up in SysEx. It's cumbersome but well organized. In fact, I can't think of many parameters that aren't addressable. Of course, file operations (saving, deleting, etc.) aren't supported, but I don't think that's mission critical to a viable editor.
My point is... a comprehensive API already exists (essentially) and it's simplicity, extensibility, and minimal entry points makes it easy for Kemper to maintain its walled garden.
A editor is still a TON of work, but 98% of the tools are already in place.