Disclaimer: These assumptions are based on a quick glance at the codebase
It looks as if the interfaces are used as a "disguise" for entities to be directly used as domain objects / dtos. This does have a small advantage in that instead of passing around a raw entity, you pass around the interface. However you end up having to write an interface for every entity, and you're still passing around entities even if they're disguised. The interfaces even have setters, so it doesn't protect the entity from misuse.
So instead of interfaces? Convert your entities to domain objects. You still have a layer of abstraction, but instead of empty interfaces you have nice domain objects that you can put business logic into. Prefer an anemic domain model? You could map the entities to dtos, with services containing the business logic for them. This isn't far from the interface approach, but it allows for more leeway as the dto isn't tied directly to the entity like the interface is.
But as software development is half engineering and half art, the entity/interface approach might be great in the Broadleaf project. Unless you understand and intend to implement the same architecture in your project, it doesn't make sense to do it unless you can justify it to yourself.
Apparently this design has been discussed a lot long time ago
https://lostechies.com/jamesgregory/2009/05/09/entity-interface-anti-pattern/
And looks like some fool has answered a somewhat related issue (where the interface is a bit different) on SO: https://stackoverflow.com/questions/27183825/should-the-entity-class-implements-interface
Also related https://stackoverflow.com/questions/18109547/orm-entities-vs-domain-entities-under-entity-framework-6-0
