For the dev building the library static typing is a very convenient thing to have. All the ins and outs have very clear rules enforced at compile level.
However, for the user of the library, it simply gets in the way. This may be avoided though if the library has been designed well enough that strange internal types are not exposed to the user unless absolutely necessary.
Actually, I find the opposite to be the case--static typing helps me use unknown libraries. The types immediately let me know exactly what a function expects and what I should expect from a function. They also prevent me from using things incorrectly most of the time.
Essentially, the types are compiler-enforced documentation. They also make discovering functions easier--a type is a succinct summary of what a function does, so I can just browse by types to find what I want quickly. Augment this with great tooling like Hoogle (a type search engine) and you've got a truly awesome development system.
A point to consider is that having .net or php on a resume gives a lot less information than say having ruby or python.
As a hiring manager I want developers who are interested in their craft beyond merely what they learned in school. Seeing experience with obscure tech or less popular languages is an easy way to spot this.
Assuming the candidate can back up what they say on the resume, it shows that they have enough confidence and ability to go off the beaten path.
