Why should I strong name assemblies, when I have to manually turn of the Bypass-Feature?

Question 1

So since .NET Framework version 3.5 Service Pack 1 strong names are not validated

Well, as a blanket statement that is not actually true. It is partially true, they are no longer validated iff the app runs in Full Trust and the assembly is stored in a trusted location. Local machine or Intranet zone.

At build time you have no reliable idea whatsoever where the assembly is ultimately going to be stored. You might have a deployment plan but plans like this tend to be overruled whenever it is convenient or necessary. This includes the need for a strong name when you need to store the assembly in the GAC. A work-around for a DLL Hell problem perhaps, something that may well need to be done years from now.

Pretty doggone inconvenient that such as solution isn't available because you didn't strong-name the assembly. And almost always too late to do anything about it by then since it requires rebuilding everything. Strong-naming is dead-simple, few good reasons to skip it. Or just suppress the message if you disagree with it, code analysis rules do fit the "have you considered this?" category of warnings. Gentle reminders of obscure details.

Question 2

If the possibility of maliciously changed (or otherwise malformed) executable code is of no concern to you, the two other reasons for going with a strong-name is (1) versioning (e.g. DLL hell issues) and (2) naming protection (i.e. unrelated code that coincidently has the same name for its assembly as for yours).

Besides, the bypass feature you mention is a performance hack that leverages upon an assumption in order to (hopefully always safely) skip the integrity checking (malicious or malformed code detection) step.

Worthwhile reads: http://msdn.microsoft.com/en-us/magazine/cc163583.aspx, and http://www.codeproject.com/Articles/8874/Strong-Names-Explained