Given that the payload is a 32-bit integer, I’d say this could easily have been written as an immutable struct, probably with no impact on performance. Whether you’re calling a mutator method that changes the value of a 32-bit field, or replacing a 32-bit struct with a new 32-bit struct, you’re still doing the exact same memory operations.
Probably somebody wanted something that acted kind of like an array (while really just being bits in a 32-bit integer), so they decided they wanted to use indexer syntax with it, instead of a less-obvious .WithTheseBitsChanged() method that returns a new struct. Since it wasn’t going to be used directly by anyone outside MS’s web team, and probably not by very many people even within the web team, I imagine they had quite a bit more leeway in design decisions than the people building the public APIs.
So, no, probably not that way for performance — it was probably just some programmer’s personal preference in coding style, and there was never any compelling reason to change it.
If you’re looking for design guidelines, I wouldn’t spend too much time looking at code that hasn’t been polished for public consumption.