While the domain of e.g. private securities may be complex, this usually isn't the main problem for developers; I'd argue this article isn't about legal requirements and the like so much, but about the actual implementation thereof. In the case of a complex domain, stick to writing the requirements and don't try and invent new things or what-ifs, because those may end up causing those legal issues.
That said, the reality is that a lot of developers are also expected to be domain experts and work independently, including knowing a lot of the legal requirements. More in my field, that's stuff like GDPR and A11y compliance (WCAG 2.2 level AA will be a legal requirement for most companies come 2025, see the European Accessibility Act [0])
[0] https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...
>I'd argue this article isn't about legal requirements and the like so much
Yes, it fails to address that other businesses face additional complexity and constraints that they don't have and then broadly over-prescribed their principles.
I'm genuinely curious how you're separating "legal requirements" from "implementation" (of either product, or process). When you build things, you have constraints, and you have to respect those constraints, or you built something lousy. If understanding those constraints is part of the building process, then trying to find the fastest way to incorporate those constraints into the product while minimizing time this blocks product development (and thus, velocity), seems like the obvious thing to optimize for. So I don't understand how you're trying to separate those (and to to be overly clear, I'm asking out of genuine curiosity to understand your point better).