The first two days you spent replying to customers, and the third day you spent prototyping or writing up some way that you thought common complaints could be addressed by making changes to the product.
It was a nearly unmitigated boon to the company. Sure, the company saw it as paying for a few extra vacation days. But the program stuck around because it generated a lot of good ideas, and the direct communication between CS and product development teams was valuable.
But it was worth it.
When I ran a development shop, every year the senior staff spent a week physically working in their client's department eating their own dog-food (i.e. using the apps they built/supported). Once this was implemented it cut down on the post-implementation change requests by over half.
1. Limited provable return on investment. The effects are real but it's not like they're a panacea.
2. Human nature. There are a lot of people who are not enthusiastic about participating — because they are not cut out for the positions they're exchanging into for a spell, because they don't see the point, because they occupy a privilege place in the office hierarchy, etc.
2b) if they don't see the point, there needs to be a serious conversation and maybe consider a new hire who does understand the benefits
2c) yeah, if you're too important to want to improve the business, let's have you talk to the two Bobs. What is it you actually do here?
In my experience advocating for such initiatives — and I have done so across multiple organizations throughout my decades in the workforce, and not just at tech companies — it is not so much resistance from below as from above that stymies them.
I did just that on my last project and it was great. Another team was developing a similar product, but they didn't have an 'in house real user' so theirs was much harder to use.
Quickly pops people out of their focus on local optima, to better see the whole.
I don't have a ton of experience with SoX compliance specifically.