Yes, it is a best practice and you really ought to do it especially considering the fact that you are shipping this code to customers (I consider strong-naming to be less critical in an internal or web-based application).
For an explanation of this rationale please see Strong-Named Assemblies:
A strong name consists of the
assembly's identity—its simple text
name, version number, and culture
information (if provided)—plus a
public key and a digital signature. It
is generated from an assembly file
(the file that contains the assembly
manifest, which in turn contains the
names and hashes of all the files that
make up the assembly), using the
corresponding private key. Microsoft®
Visual Studio® .NET and other
development tools provided in the
Windows Software Development Kit (SDK)
can assign strong names to an
assembly. Assemblies with the same
strong name are expected to be
identical.
You can ensure that a name is globally
unique by signing an assembly with a
strong name. In particular, strong
names satisfy the following
requirements:
Strong names guarantee name uniqueness
by relying on unique key pairs. No one
can generate the same assembly name
that you can, because an assembly
generated with one private key has a
different name than an assembly
generated with another private key.
Strong names protect the version
lineage of an assembly. A strong name
can ensure that no one can produce a
subsequent version of your assembly.
Users can be sure that a version of
the assembly they are loading comes
from the same publisher that created
the version the application was built
with.
Strong names provide a strong
integrity check. Passing the .NET
Framework security checks guarantees
that the contents of the assembly have
not been changed since it was built.
Note, however, that strong names in
and of themselves do not imply a level
of trust like that provided, for
example, by a digital signature and
supporting certificate.
When you reference a strong-named
assembly, you expect to get certain
benefits, such as versioning and
naming protection. If the strong-named
assembly then references an assembly
with a simple name, which does not
have these benefits, you lose the
benefits you would derive from using a
strong-named assembly and revert to
DLL conflicts. Therefore, strong-named
assemblies can only reference other
strong-named assemblies.