The Cap’n Proto docs provide some motivation for promise pipelining: Cap'n Proto: RPC Protocol
TL;DR: if you’re in a latency-sensitive environment, there are a whole bunch of nice API design patterns that become unusable without promise pipelining, because they make too many round trips.
I tend to lean on this really heavily when designing atop capnp. The same reasoning would apply to Goblins, of course.
This is sort of maybe true, but I think is true even without promise pipelining. Sending a message to a forwarder which is set to itself and will also go into an eventual loop, and a lot of our designs rely on proxying. (And eq? won’t fully save you… instead of A forwarding to B, A can forward to B which forwards to A…)
The promise pipelining approaches in Goblins and also in E (IIRC) can detect certain kinds of circular forwarding patterns (but not all) so one might argue they do a little better in the unintentional case.
You are right that metering is very possible and that the technical approaches that we’re taking make it even more amenable to it. That said, everyone needs to agree on a metered language. Promise pipelining is fairly easy to set up, and we already have ergonomics that align with it.
Still, I won’t complain about you getting excited about showing how easy it is to add metering to the metacircular evaluator. 
From Promise Pipelining
For the sake of modularily, we seek to carve up our systems at good abstraction boundaries. For security, we wish to make divisions at trust and administration boundaries. For partition-survival, we divide to enable continued meaningful (if degraded) operation of the separated components. Fortunately, these three should correlate, and do in practice.
But we’d also like to spread our distributed computations across separate machines according to the performance consequences. … However, this is often at odds with modularity goals. “Higher-level” often means more specialized, or policy rather than mechanism . Good modular systems of abstractions should normally export orthogonal composable primitives which are useful only when composed, but leave it to their clients to determine which composition to use. But this causes the client to compose several invocations to do any one useful thing.