Division of labor
A car is a machine whose function derives from chemistry, i.e. the combustion of fuel (chemistry). But the people who build cars on production lines are not chemists nor chemical engineers.
Someone else worked out the chemistry behind combustion and how to transfer it into motion, and designed the plans for a machine to harness that power. Those plans were then given to the production line workers, who are implementing the steps described in the plan, without it requiring them to understand the bigger picture of how it all comes together.
A car cannot operate without fuel, yet a car can be built according to specification without any fuel. Specification is the operative word here. For software developers, that's the requirements that are described in the functional analysis. It contains all the information that is necessary to know how to build the application (similar to the steps describing how to build a car).
That being said, it is true that car builders will usually have a higher-than-average understanding of how cars work as they are surrounded by the subject matter on a daily basis, but that doesn't mean that anything above a basic understanding is a necessity for their job.
Similarly, due to contextual business rules developers will generally acquire some understanding on how the field works, but that's a side effect from working the job, it's not a required skill to work the job.
Curiosity and osmosis
Back to the software engineering example, the same thing is happening here. Let's say you have biologist customers who want an application to track their inventory of DNA samples.
Right off the bat, software developers will generally omit field-specific details (in this case related to biology) to focus on the underlying (more reusable) principle. Most developers would very quickly identify this application as being structurally similar to other applications from completely different fields, e.g. a warehouse inventory system.
This actually proves the point that on the outset, you don't need field-specific information, as a lot of applications are structurally similar even if they are used in different fields. That's pretty much the core essence of what a developer does: finding the abstract and reusable logic/architecture that's not contextually unique.
However, then we get to the implementation details, and here there may be context-specific exceptions or rules. I'm no biologist, but let's just invent something and say that DNA samples that are more than a week older than another sample cannot be stored adjacent to one another.
Most of the time, the functional analysis will already cover for these rules, with pretty much the exact description I used just now: "DNA samples that are more than a week different in age cannot be stored adjacent to one another".
You don't know why that is the case, nor do you need to know. The rule as phrased in the analysis is enough information for you to implement the necessary logic that would prevent biologists (end users) from wrongly storing these kinds of samples adjacent to each other.
However, we're still humans who are curious about things we don't understand. That counts double for developers, as they tend to display character traits like seeking out puzzles and looking for answers.
It's very likely that when a developer is asked to implement this business rule, they're going to ask why that is the case. Not because it's necessary knowledge, but as a matter of casual conversation or personal curiosity.
Your question is build on the premise that this field-specific information is necessary, but it is not. It's simply something that you will generally accrue while working in the context of that field, due to random conversations you either overhear or are part of, and possibly some field-specific business logic that reveals how certain parts of a field work.
Imperfect requirements
There's one more thing to consider which I haven't really addressed yet. You cannot reasonably expect a functional analysis to be perfect. There are always going to be some mistakes or gaps in the document.
If we're talking about gaps in the custom business logic, then this is where having field-specific contextual knowledge can cover for those imperfections.
So you could argue that the quality of a functional analysis in inversely correlated to how much field-specific knowledge your developers should have. The better your analysis, the less your developers need to figure it out for themselves, and therefore don't need to have any real field-specific knowledge.
Anecdotally, as a consultant I've been sent to several development teams where they had a lacking development framework (most commonly in the analysis department), and the developers in those teams were often highly aware of the field in question and how the customer operates.
Conversely, when I was sent to customer who did have a well-rounded analysis/software spec, developers were generally able to focus on development itself and did not require (nor focused on) the field in question as much.
It's my observation that a lacking/bad analysis leads to a tighter coupling between a developer and the field of their end-user, simply to cover for the knowledge gap that the software requirements are supposed to fill.
A good functional analysis separates the developers from the contextual field as best as it can, leading to developers being able to shift more of their attention towards actual development. This cycles back to the division of labor that this answer started off with: car builders (software developers) shouldn't try to be chemical engineers (biologists). It's not what they're good at.
