No, there is no additional protection against remote exploits, but you should always set an account password wherever humanly possible, for a whole host of reasons not related to remote code execution bugs.
Remote exploits usually result in code execution, and that code would run under the privilege level of the user that was running the exploited service or application. As such, the password mechanism is entirely bypassed.
This is especially the case for services running under dedicated service accounts, such as NETWORK SERVICE, LOCAL SERVICE, or SYSTEM, which don't technically have passwords in the first place - they have NTLM hashes with random values, and login is disabled for them.
The only protection I can see is in a scenario where a low-privilege user (e.g. a limited or guest account) runs an application that is open to the network, and that application is exploited. From there, a passwordless account is a target for horizontal privilege escalation, or vertical privilege escalation if the account runs as administrator.
All in all, I would suggest that a password is always set on all user accounts, but not for remote exploitation protection reasons. There are so many other reasons to set a password.