Yup, it does. Filed as SR-12715.
It's worth noting, however, that while it's statically knowable in your current case, several years later someone can come along and change the size of the array without changing the subscript, and now your code is broken. The downside of doing things that aren't safe is that while your code may be safe today, it can easily be wrong tomorrow. Having the compiler back you up provides value.
We should also try to be clear about the performance conversation we're having. In the straightforward case, we're talking about an extra cmp and a (highly-predictable) branch. Two instructions, one very cheap and one often cheap. While there are some code paths where this cost matters, in most cases it does not. Benchmarking the code in question will usually reveal a much more important performance optimisation available to you than the cost of the bounds check.
There is one major exception here: Swift's logic for bounds checks inhibit vectorisation if they can't be elided. This often is a major performance delta on large arrays. Anytime you see that fail to happen it really genuinely is worth a bug report, because here the optimiser will achieve a substantial improvement if it can vectorise.