A hardcoded version number makes sense if you want to enforce versioning at design time. On the contrary, a version value makes sense at runtime.
Design time versioning tightly couples service consumers to the service version. Upgrading the service version means all consumers must upgrade. A version number in the namespace translates to package in Java. Changing the number is changing the client code.
Runtime versioning is much more flexible, and has less impact on client code. But runtime versioning does require an effort in governance. Who is using which service version? Who is upgrading when?
Changing the version number in a namespace can trigger a cascade of changes in other XML schema, e.g., through schema imports. This can be so complex that I have seen several large web service providers still being at version 1.0, even after numerous non-backward compatible changes. Effectively this is a no-version strategy, where each change pushes high costs onto all consumers and governance is not stimulated.
Runtime versioning is more friendly towards consumers, and ensures that proper governance is put in place, which increases the service maturity level.
It can't be a surprise I favour the runtime versioning strategy.