First, it seems like we both agree that having the flexibility to extend a base model is a good thing, whether that base model is OPA or Zanzibar.
I wouldn't call the ABAC scenarios "non-deterministic" - for the same inputs, it should produce the exact same outputs. But those inputs may include data that is sourced from the environment the user is in (e.g. date/time, location/IP address, etc).
Where model you start with is probably up for debate. To me, ReBAC starts making sense when there is a resource context to evaluate. There are plenty of customer scenarios we've encountered where modeling permissions for operations is sufficient, and doesn't require a resource context (or the resource context is very lightweight - e.g. "tenant", "project", "team", "organization", "list", etc)
I use the following as my "rule of thumb": ReBAC databases want to have deterministic computation for your permissions. In the default case, this should be your ideal as well as it is the most understandable/scalable/testable/auditable/debuggable. But reality is that there will be places where you'll want _some_ non-determinism and in those scenarios it makes sense to leverage policy engines.
The SpiceDB community is exploring what it might take to support adding lightweight policies to the Zanzibar-like model to have the best of both worlds. If that sounds interesting, you can participate in the proposal[1].
[0]: https://github.com/authzed/spicedb
[1]: https://github.com/authzed/spicedb/issues/386