Golang Naming Conventions

I've been working with Golang off and on since college. When I first
encountered the language I knew Java and C, and I was thrilled to be working
with a language that felt modern yet familiar. The language's opinions were
sensible but things like type-inference, simple concurrency, and duck-typing
were refreshing. I no longer feel this way

Now, I feel like every time I encounter an opinionated decision in Golang's
design or prescriptive style I disagree with it. Not just "I don't like this"
so much as "I don't understand how this could be a positive choice". The
perfect example of this is actually a part of the Go Official Style™ [1]:

Initialisms are, by standard, consistently cased. So if you have a VOIP ID or
Target Group ARN they want you to write it VOIPID and TargetGroupARN instead of
VoipID TargetGroupArn. This degrades the readability of the variables and the
ability to break the var into words. When you camel case initialisms you are
able to intuitively break up VoipId into VOIP and ID. This is more difficult
with VOIPID or voipid. God forbid you need to do so programmatically.
Without a dictionary of initialisms most programs would break the first example
into the words "V", "O", "I", "P", "I", and "D". Us humans have a dictionary
of initialisms in our brain, so all we need to do is try and figure out where
to place the delimeter.

Of course Golang has a solution for this: mix and match! Use lowercase for one
word and UPPERCASE for the next. Easy! voipID and VOIPid (in the case of a
public field) are easy and only come at the cost of inconsistent casing.
Of course this breaks down if you have three in a row.

> VoipXmlId
> VOIPXMLID
> VOIPxmlID
> voipXMLid

Someone please tell me what could possibly be a defense for this. I can't
fathom what we gain from this casing convention.

{[1] Golang official initialisms convention}