While the author of a webservice can generate a WSDL file from java, the client may not have nor get a java file representing the soap call typeor return type. It's a matter of convenience and accuracy in recreating the class as it was intended. It's not the only way of using SOAP, but if you wish to use dynamic proxies, going from WSDL -> java (or perl or whatever) is a lot shorter to write.

Typically, w/ dynamic proxy, you create and use objects that work remotely and passed back in fashion as if they were locally there. SOAP would create the objects for you via some factory, sometimes off of WSDL.

example from SOAP::Lite

use SOAP::Lite;
  $service = SOAP::Lite -> uri('urn:QuotationService')
               -> proxy('http://localhost:8080/soap/servlet/rpcrouter'
+);
  $result = $service -> getAllQuotations() -> result();
  $i = -1;
  while ( ref $result->[++$i] )
  {
    print "$result->[$i]{'text'} ($result->[$i]{'author'})\n";
  }
[download]

If the author of SOAP::Lite, for perl6, wants to make hashes that cannot be assigned arbitrary keys, or for speed reasons, create classes from pre-existing object files, may need to pregenerate the perl. I'm still fuzzy on how perl6 works, so forgive if I use the wrong terminology :) I'm sure there can be a way of generating objects and later choosing to lock down their attributes.

So anyway, having pre-generated code for wsdl is always useful for soap writters (toolkit or end user) who would need type clarification for knowing what's accessible and what doesn't exist. After all, what you pay for in dynamic-ness, you save by apriori knowledge especially in intense applications.