The short answer is: if publishing a WSDL presents a security problem, then you have a security problem, even if you are not publishing a WSDL, and you need to fix this problem, not just hide it.
WSDL just explains your protocol. You cannot assume that your protocol is a secret; attackers can still reconstruct it without your WSDL. You can never assume that the client on the other side of the network connection is “your” client. You must assume that this is an attacker and the design of your system to deal with this fact.
So hiding your WSDL is a secondary form of obfuscation that does not provide serious security. But ... if hiding your WSDL is very easy and does not require additional work on your part, of course, why not? Hiding can potentially prevent some types of automated scripts from attacking you. And this creates one extra small headache for attackers.
One of the main threats to hide your WSDL is that it may cause inability on the part of developers who believe that WSDL is secret. If you have a team for which this could be a problem, I would leave it publicly available to keep them in focus.
Another serious danger is that it makes your system more difficult (which makes updating difficult, for example). If this were so, I would not hide it. The added complexity of clients will almost certainly be a greater security risk than public WSDL.