This feels like an instance of the XKCD:927 principle. Math notation tends to be big and ugly and hard to wrap your head around at times. It's context-specific (if you're summing over an array, you'll maybe use i as an index value and reference x_i. If you're working with complex numbers, i is a constant.
Importantly, this language and its practices have evolved over centuries, in response to a lot of different competing needs. It's probably highly-optimized for something, just not what you need it for.
That said, if you're dealing with indices of an array in a sum / product series and that array is of complex numbers, it's actually not terribly ambiguous to do x_i * (2i - 1) or something.
On the other (third? gripping?) hand, you do have a point - there's usually unwritten practices about what different variables reference (theta is usually an angle, k is a constant, n an integer, usually). That can be gatekeeping, and it's super-frustrating to work in a language that doesn't expose type information.
Importantly, this language and its practices have evolved over centuries, in response to a lot of different competing needs. It's probably highly-optimized for something, just not what you need it for.
That said, if you're dealing with indices of an array in a sum / product series and that array is of complex numbers, it's actually not terribly ambiguous to do x_i * (2i - 1) or something.
On the other (third? gripping?) hand, you do have a point - there's usually unwritten practices about what different variables reference (theta is usually an angle, k is a constant, n an integer, usually). That can be gatekeeping, and it's super-frustrating to work in a language that doesn't expose type information.
927: https://xkcd.com/927/