Tainted = aware of non-public information that must not be incorporated into the product, so it's easiest to just not let those people work on it at all.

By only allowing people who don't know anything secret to work on a product, you keep the product safe from allegations (justified or not) of illegally incorporating third party material.

If you don't do it, you risk that a competitor claims "your product contains our proprietary material, pay us royalties or we'll sue your customers". Even if you're 100% in the right, until you've had that decided in court, your customers have to worry about getting sued, and you'll lose business (and also spend a lot of money on lawyers).

The model is particularly known/used in reverse engineering: One team (that is not tainted with knowing any NDA'd materials, I assume) looks at the product you're trying to reverse engineer, and writes a specification. Another team (not tainted by NDA'd knowledge or knowldege of the code of the original product) then implements the spec. https://en.wikipedia.org/wiki/Clean_room_design

Wouldn't the liability only be with the company that allegedly stole the secrets? How would the customers be implicated?

Many avenues lead directly to the customer. Linksys used gpl code illegally and when they were found out they had to release updates across all of their products, causing some of their lines to be end-of-lifed earlier than expected. Customers are definitely impacted by that.

How about security secrets which directly impacts the customer?

The question wasn't how could the customer be impacted. None of those scenarios have to do with the customer being held legally liable for the IP violations of a vendor whose product they use.

That's a reference to clean room design - you don't want to be accused of stealing a competitor's design, so anyone with knowledge of that design is considered "tainted" and not allowed to work on your core systems ("kernel").

https://en.wikipedia.org/wiki/Clean_room_design