This is an important point. One of the criteria we've discussed before for justifying addition to the standard library is that it helps people avoid common correctness or performance traps.
To run down the full list, I think this qualifies on a number of levels:
Readability: array.count(where: predicate) is much more readable at a glance than the composed alternatives using lazy.filter or reduce.
Commonality: this is always a subjective one, but I think it's clear this is a common need, and not tied to a specific domain.
Performance: This implementation avoids a performance pitfall of creating an intermediate array. There's also an argument that the Equatable version should be a customization point since some collections can implement it more efficiently (cue @jrose expressing concern we have too many of those).
It doesn't qualify on grounds of being hard to implement, and also (probably) doesn't qualify on grounds of needing access to internals to be more efficient.
I see this as similar to isEmpty, which is trivially composable as startIndex != endIndex but is more readable and avoids people accidentally writing the often-linear count > 0.
edit: ha, I mean startIndex == endIndex of course. Not so trivially composable after all!