I really like what you're doing here, but oh my goodness that Jsonnet cries out for a more readable format which lets one focus on the semantics more than the mechanics of the mixins.

This looks way more legible to me:

    (service make-it-rain (gocardless/make-it-rain)
      ;; Example service called make-it-rain, powering a dashboard of falling
      ;; gold coins whenever anyone takes a payment via GoCardless.
      ;;
      ;; Banking teams love money, which is why they created this dashboard.
      ;; It's officially owned by banking-integrations, but core-banking
      ;; sometimes optimise the React code.
      ;;
      ;; It consumes data about new payments from Google Pub/Sub, and has a
      ;; separate Google Cloud Platform project for each of its environments,
      ;; of which there are two: staging and production.
      (team banking-integrations)
      (alerts-channel make-it-rain-alerts)
      (google-services pubsub.googleapis.com)
      (environments
       ;; By default, every environment should have banking-integrations as
       ;; admins, and core-banking as operators (they provide on-call cover
       ;; for the falling gold coins).
       (* (admins banking-integrations)
          (operators core-banking))
       (staging
        (google-project gc-prd-make-it-stag-833e)
        (argocd.new (cluster compute-staging-brava)
                    (namespace make-it-rain)))
       (production
        ;; Unlike most services, the production environment should permit
        ;; a non-engineering team to open consoles. Sometimes we take a
        ;; manual payment outside of GoCardless, and banking-operations
        ;; open a make-it-rain console and run a script, so we don't miss
        ;; any gold coins.
        (operators banking-operations)
        (google-project gc-prd-make-it-prod-1eb1)
        (argocd.new (cluster compute-banking)
                    (namespace make-it-rain)))))

It would be really easy to write, too. Basically a service takes a mandatory name & repo, then all other elements are mixins. You could take a couple of different approaches with the way the environment mixin works, too. You could still compile it to JSON, if that's what you need downstream, too.

I think there's a huge win in having a more man-readable, machine-computable format that JSON or Jsonnet: as the system and the tooling grow, I think eventually the Jsonnet will become an unreadable mess of spaghetti (some might argue the example already is!), while a well-thought-out S-expression alternative would not, I think, have the same problem.