That was roughly the reading of this issue that I assumed initially too, but in fact the liability/reward situation is reversed here, I think.
GitLab are considering making this change in order to satisfy the requirements of a potential customer[0] - i.e. the reward is for adding the restriction.
And in turn, making the change itself could increase liability[1] since it doesn't seem to be based on a legal request or existing defensible GitLab policy.
[0] - https://gitlab.com/gitlab-com/www-gitlab-com/issues/5555#not...
[1] - https://gitlab.com/gitlab-com/www-gitlab-com/issues/5555#not...
The thread reads like a case of the compliance arm of the business trying to keep the ship steady and non-discriminatory (which is in-line with GitLab's stated goals, the intent of the law, and likely in-line with their prospects as a long-term global employer), while a sales part of the organization tries to close a deal.
Putting in additional engineering effort to allow the customer to specify their own policy on SRE/support access to data -- which they'd be responsible for defending if there were any questions -- seems like it might be a way forward. Whether the sales team and customer would wait for that is another question.
It's remarkable and very progressive to see this discussion in the open; it's also interesting to note how many side-discussions and different opinions emerge in the comments and in discussion here, while the core communication continues between a small number of participants in the merge request.