Christian's comment reminds me what I forgot to mention - we did (as Christian has recommended) separate our most truly common and reusable objects and expressions into a central rules application. We specifically separated out common Decision Tables, Decision Trees, and Constants, and put them in a central Catalog as well to assist business stakeholders and rule designers to find them.
More than just making it clear to rule designers and developers which objects were reusable, it also allowed us to multi-deploy the common rules application to multiple systems from Decision Service Management (btw if you don't yet have DSM you can also use XML Export/Import for the same effect) - so that rules applications in both of our systems could access the common elements.
There's always a balance here - too big a rules application becomes hard to manage, and it can become quite slow to work with it in the BRFPlus workbench; too many rules applications makes it harder to find the object you are after and building effective catalogs is trickier.
For the most part we went with putting related functions, mostly those that dealt with the same logical business object, together into the same rules application. But it's a judgement call to balance performance in the workbench and during execution, against clarity of organization.
Good luck!