Zacharmarz briefly touched on it in his comment; however, it's less about performance and more about configuration.
In the first example the sampler state is left uninitialized and works just like any other parameter (e.g. your
WorldMatrix) - this would allow your game to change the sampler at runtime. Conversely your shader won't work if you don't initialize the sampler. Most often you will see this syntax in conjunction with custom
SpriteBatch shaders as they would allow the
SpriteBatch to provide crucial configuration.
In the second example the sampler state is 'hardcoded' into the shader. This means that once the shader is compiled it's set in stone - your game can't change it if it needs to.
Both techniques are just as viable as the other - it all depends on how you intend to use the shader. If you need the sampler configurable use the first, if you require that the sampler is always in a predictable state use the second. It is much more likely that you will be using the second method.