Create Security Policy without schemabinding Create Security Policy without schemabinding?

Is this a bad idea? I have an indexed view in another database that I need to use in my security predicate for row level security. I can either turn off schemabinding and use a synonym, or I have to start using transactional replication to copy to a table in the main database. I control both dbs and they are on the same server.
The security policy documentation incorrectly states that the inline table value function must have been created using the SCHEMABINDING option. The actual behavior, however, is that the function needs to be schema bound only when the policy is schema bound (default). Since the function with cross-database references cannot be schema bound, the implication is the policy cannot be schema bound either.

Without schema binding, the onus is on you to ensure no breaking changes are made to the function or dependent objects and that the other database is always available. Also, users will need SELECT and EXECUTE permissions on the function as well as SELECT on objects accessed by the function (not necessary with SCHEMABINDING on the function). This may be a security concern depending on the sensitivity of the predicate data.

I think the general best practice is SCHEMABINDING for the above reasons but you'll need to weigh those benefits with the costs of managing replicated data.
Besides transactional replication, you could use an ETL process or Service Broker to replicate the security policy data. Not sure why the data is in a different database to begin with but another option would be to move the objects to the same database.