Based on my experience of a database where million of records are present and being operated for inserted/updated/deleted in a year. We were having proper constraints for data integrity purpose and there was no problem at all in intial time, but later on DML operations getting slower and reached to unacceptable level sometimes failed to execute. Then we removed the constraints to get performance back in the database.
Hence for SELECT operation definitely there is a benefit else DML operations will be slow later on based on amount of data.
Are those DML operations for individual records or large sets? And if for sets...even as large as full table updates?
And what is the size of tables being referrenced? Many tables being refferenced are lookup tables for things like record status. These are critical to keep correct or else all business logic on top turns to jelly. I would never sacrefice this sort of RI for speed gains in this area.
If there is a clear situation to advice no referential constraints in, it would be prudent to scope that advice properly. Not every FK constraint has identical importance if you are forced to choose!
Did you check if there were needles updates being done on the foreign key fields (like no changing values)? I ain't exactly certain what happens when you update a field with the same identical value. For indexes i think i know the index update doesn't get done as it is not needed. But for foreign key constraint checks....i am not certain. It could even different between SQL Server editions.
It is worth a few tests, as throwing out RI rules just to gain speed sounds like the last thing one wants to do!