Depending on your organizational structure, I would also mention that it really isn't their decision to make; it's more of a business decision.
Does the business know of
1. the existence of orphaned records and how it is affecting the data integrity
2. the potential of orphaned records and how that might affect the data integrity
3. Are the business rules being enforced?
I've seen the argument for not using FK's and enforcing business rules in the application, as well as parent/child relationships. For me, I haven't been convinced that it's better to not use FK's. One of our core responsibilities as a DBA is to protect the integrity of the data. We need to do everything within our power to do so, but due to business requirements do not always "win", but at the very least, the business is aware of the ramifications of not enforcing rules. I'd also document their decision.
Even still, on a number of occasions I've advised the business that something may need to be enforced or tables/schemas should be set up a certain way to prevent future problems or to provide for future features and they said they cannot see the situation where it was necessary. Then a year or two later, they want the recommendation and even though it was documented, "rework" had to be done.
Do you have the support of your manager? What are the database and application standards at your organization? If you don't have any database standards, consider writing some up and presenting them to your manager and the team.
The best you can do is maintain your integrity by making the case to the business and documenting the results.
Best of luck,