The fact that the at method coerces values seems to be a decision that the committee is not ashamed of. This is how the language's built-in API has always worked, and they don't plan on breaking this pattern now - you can see more discussion around this here. So, any idea around breaking this long-standing tradition of coercing values probably won't get very far. Yes, it's annoying and horrible, I think everyone agrees with that, including the delegates, but they understandably prefer keeping the language consistent, than trying to change course with newer APIs.
I can also see your desire for having parity with forward and backward indexing, and having them both start from zero, however, I would have to agree with @bergus on this point. There's already precedence in the language (and many other languages) that negative indexing starts at minus one. array.slice, array.copyWithin, array.indexOf, string.slice, etc, and now array.at are all following this pattern. Introducing a new function, whose main difference is that indexing starts at minus zero would be incredibly confusing, now people have to memorize which functions uses which form of negative indexing. Plus, if we're going to add a new "at" method for negative-zero indexing, shouldn't we also add new "copyWithin", "slice", "indexOf", etc methods for the same reason? And, like @bergus said, most developers probably don't realize that negative zero is different from zero - I wished negative zero did not exist, and wherever it's possible, I would like to make negative zero and zero act exactly the same.