Not the OP, but our company Measured is building Puck as an open source project, so I'll try and answer.

Puck is targetted at content/CMS use cases, rather than general UI building. So the ability to establish guardrails in the editor experience is intentional. For best effect, we envisage Puck being used alongside a well-considered library of on-brand composable components. The aim is to enable non-developer editors/authors to freely update and build content, whilst keeping the UI consistent and on-brand.

This is a problem area we've encountered many times in our client work, hence why we wanted to scratch this itch.

Having said that, I do believe the Puck editor GUI _can_ be configured to work with remote data somewhat as you describe, using the adaptor linked above (but there's currently no demo for this feature).

Scott from Measured here, we're dog-fooding puck on https://measured.co.

There's a WIP branch with support for more sophisticated layouts here: https://github.com/measuredco/puck/tree/nested-dropzones

And I think `use client` is a Next 13 thing. Not sure of the details, but Puck definately does render server-side.

+1 what Scott said

Multi-column layouts are incoming very soon

And Puck does support either server or client rendering