I think it's definitely worth supporting differing depths of reference embedding along different paths. Ideally though you want want to select which properties are included as when you get to several levels of embedding the resulting document is very large and often you only need a subset of properties expanded for the embedded documents.

Additionally it can be very helpful to embed along reverse references (parent.children from the reference stored as child.parent.)

Concrete example, take this page on a scientific data portal: https://www.encodeproject.org/experiments/ENCSR807BGP/

The JSON-LD document representing that object itself is: https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... and many reference paths are expanded to generate the JSON required to construct the UI: https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... (this is larger than it needs be as the entire referenced document is embedded rather than just the necessary proeperties.)

While pre-generating the deeply embedded document means fetching it is fast, as the site has grown keeping them up to date becomes challenging so I've been looking at options for embedding dynamically.

That's correct.

"I think it's definitely worth supporting differing depths of reference embedding along different paths."

Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.