As others have mentioned, the problem is not necessarily the potential extra cost - assuming it could be a paid add-on, nor really the file size - which doesn’t matter all that much these days.
The main problem is - as mentioned above by @davidcockey - would be the integration of the parasolid kernel to work alongside and with Rhino’s native geometry engine. This could potentially take a long time and lots of work to figure out and get working correctly - and those costs would need to be borne by the probably limited number of users of the add-on. Or they would have to be passed on to all, meaning higher prices or lower profits.
However, in my mind, it is not necessarily the economics of the operation that are the most problematic. Assuming you have parasolid kernel created/controlled objects coexisting with Rhino kernel created/controlled objects in a Rhino document - how do they interact? Being able to go back and forth is probably the stuff that nightmares are made from.
Also consider this: Parasolid is a 3rd party library. As such Rhino would become (partially) dependent on what that third party develops and decides what to do with their product (including pricing!). If there are bugs or limitations one has to wait until the third party decides to fix them or not and release a new version. New versions could potentially break some existing functionality when integrated into Rhino.
Right now McNeel has pretty much complete control over its geometric engine. This allows developers to fix bugs and add new features as fast as possible without relying on an outside entity. It allows McNeel to determine its own design direction. This independence is (IMO) a large part of what makes Rhino what it is today.