https://www.w3.org/TR/WGSL/#attributes states:

If align(n) is applied to a member of S with type T, and S is the store type or contained in the store type for a variable in address space C, then n must satisfy: n = k × RequiredAlignOf(T,C) for some positive integer k.

This rule is unnecessary, as https://www.w3.org/TR/WGSL/#address-space-layout-constraints states:

Structure members of type T must have a byte offset from the start of the structure that is a multiple of the RequiredAlignOf(T, C) for the address space C:

OffsetOfMember(S, M) = k × RequiredAlignOf(T, C)
Where k is a positive integer and M is a member of structure S with type T

So, if you provided an explicit @align value that misaligned a member w.r.t. the address space usage, then this would be caught by the layout validation anyway.

The rule also seems broken, as it can actually prevent you from specifying the default alignment for a given type:

struct S { i : i32 } // AlignOf(S) == 4
struct DefaultAlignment { s : S } // AlignOfMember(DefaultAlignment.s) == 4 - no errors
struct ExplictAlignment { @align(4) s : S } // error: 4 not a multiple of 16 (RequiredAlignOf(struct, uniform))
@group(0) @binding(0) var<uniform> happy : DefaultAlignment;
@group(0) @binding(1) var<uniform> sad : ExplictAlignment;

Finally, if we were to remove this validation rule, @align(1) could be used for tight-packing. The offset validation would still ensure that the layout is valid for the given address space usages. This would be handy for the day we support relaxed layout validation.