Well, if you're a rank and file engineer, your "job" isn't explicitly to figure out what the business needs. However, if you care about becoming more valuable over time, you owe it to yourself to understand why the business values you. The business doesn't care about the code itself, it only cares about the solutions the code creates. If it's slow, that's a problem. If it's buggy, that's a problem. My instincts tell me to accept nothing less than purity, but a business needs pragmatism and "good enough".
I only work in startups where I feel people expect me to know the business needs, I wouldn't want to work at a place where somebody 'breaks down' the business needs in small packages which need no knowledge about the business needs to implement. I think 'the good' startups realize that this old pattern doesn't work if you try to be innovative and agile.
Developers are often aware of solutions that do not occur to the business people. A business person might think we are being as efficient as we can be in process P, but then a developer may come along and say we can automate parts of process P by implementing solution S, for example.
A lot of the time this sort of thing does not happen in the scheduled, structured meetings, or in email chains, or in video conferences. It happens when people in the office approach each other "out of the blue" and decide to grab a conference room and work something through face-to-face.
And being able to resolve issues faster, and respond faster to changes, is valuable to the business.