I am thinking of multisite / multidb only because of the performance
If that is the case, then only people who have very detailed information about your site and your organization can answer your question. It boils down to comparing the resources necessary to identify and fix the performance issues, to the increased/increasing long-term resources necessary to maintain multisite/multidb. "Resources" is not just about money, it's also about time taken away from other potential projects, the relative likelihood and severity of disruptions caused by bugs/errors, etc. These things are very specific to your site/problem and your organization.
Most of the time, the right answer would be to fix the problem, and not try to bypass/band-aid it. However, there can be circumstances that doing something the "right" way, or even a "good" way, would be so cost-prohibitive for an organization, that you have no choice but to do it the "acceptable" way.
Let's say the problem is how you have structured/modeled the data on your Drupal 7 site (your description makes this a possibility). Truly fixing it may require building a fundamentally new (incompatible) structure/model in a Drupal 8 site, and writing custom modules/programs to manipulate and import the data from Drupal 7. You probably have some idea about whether your organization has the resources and know-how to pull that off with minimal disruption. If you're thinking, "sure, no problem, we can do/pay-for that", then multisite isn't a viable option, in my opinion. Especially since you have data that needs to be shared and consistent among all the sites (Project A, LIMS, and eventually an Intranet).
So, if you haven't done it already, you need to figure out exactly what is causing the performance issues. Then you can look at what it would take to fix them, and decide where to go from there.
Study_1 has 15 entity reference fields to enable different projects
within that study, and each entity ref form has between 50 - 80
I'd like to point something out about multisite/multidb: Just because your sites/databases are logically separated, does not mean that your performance issues will go away.
Let's say that you migrate to multisite, and later you realize all your performance issues are because of Study 1. If the tables/data for the "Study 1" Site is using the same physical/virtual database server as your other sites, it's possible that you will still have performance issues. Putting Study 1's database on another server may help the other sites, but it increases your cost significantly, and Study 1 still has performance issues. You can upgrade your database server to handle the load, but that increases costs as well, and you can't upgrade it each time a new study comes along with a structure like Study 1.