Smoothing out the transition from on-rails to off was one of the original design goals, so there was arbitrary server and client scripting from pretty early on, and a component model to create widgets. The project as moved from being hosted on App Engine to being hosted on Docs infrastructure, so I'm not sure what the specifics of extensibility are, but I suspect they're pretty good, but more Apps Script oriented. Should be a good solution for heavy Docs users.

My thinking in this space is that you really can have your cake and eat it too with these tools, though it requires a really thought-out design, and that they built-in features use the same extension points that are available to users.

With JavaScript available on the client and server it becomes less of an issue whether you can run code at all, and more of an issue of whether you can run at the right time and intercept the right flows. Especially with Web Components on the client pretty much taking care of components. Providing a standard router on the client and server with similar middleware and handlers, and also middleware/handlers on state changes, you can get close to easy to start with and fully extensible.