One option is to have smtk::resource::PersistentObject maintain its pure virtual methods to a Links instance as @dcthomp suggested, implement it in Project (as it is done for ResourceLinks and ComponentLinks) with another smtk::common::Links datastructure, and modify the smtk::resource::Links API to avoid the need for direct casts to children of smtk::resource::PersistentObject. I suspect it will not be long before someone will want to link some piece of information to a Project instance.
FWIW, if this seems like a fair bit of infrastructure change, it is because the original design was designed around Resources and Components; their common base class was added after the fact. The addition of a third, distinct entity and its need to interoperate with tools that were designed to handle the original use case is not a small change. I think the generalization of smtk::resource::Links to handle any subclass of smtk::resource::PersistentObject would result in a nice, extensible pattern that we could use to easily handle the next persistent object.