macaroons are bearer tokens whose authority can be attenuated by the holder and passed along elsewhere
like any other bearer tokens they are typically used when it's acceptable to have some lag between permission changes and having those changes reflected in the system. in exchange for freshness you get to validate permissions very quickly (just a few hmac verifications)
you still have to do some work somewhere in order to encode the authz information in the macaroon in the first place. this is where spicedb would fit in if you were using spicedb - it would answer the inititial questions about permissions, which you could then encode into a macaroon.
spicedb relies on heavy caching though, so a lot of the benefits you get from macaroons are mitigated by having the authz answers fast enough directly from the spicedb. and having instant revocation via spicedb solves a big problem you'd have to solve some other way with bearer tokens.
that may not always be the case, and in cases where you really need to compute permission once and then have the answer cached (but potentially out of date) macaroons can be a good fit. They can also be a good fit if you need to perform some authorization checks in an environment that doesn't have network access to spicedb, or if you need to coordinate between parties that can't rely on the same backing spicedb system.
tl;dr: spicedb and macaroons are largely orthogonal. whether or not they make sense together, or whether you only need spicedb, depends on what you're trying to do.