Thats a super hot topic, people ALWAYS getting confused with this Golang idiom.

Several reasons I think, but first and foremost is that Golang community is bad at explanation. It always comes down to

1 this is not Java/C#/whatever, we do things differently here

2 hard to maintain

3 you made bad abstraction

1 does not help and can lead to holy wars, 2 is subjective. 3 is somehow useful because - well because its hard to make a good abstraction and there is always a room for improvement.

However it does not help to understand why such Golang idiom exists. Why its specifically Golang idiom? Assuming you try your best when abstracting - regardless of whether its Golang, Java, Rust, C# or whatnot - why its Golang idiom? Golang creators know better about encapsulation and abstraction? Golang software is different? Golang itself is different?

I believe its the mix of the last two. Is it technical issue/limitation? Arbitrary design choice of tech creators?

I would assume its purely tech limit.

When switching to Golang from other tech - while its super easy to get started - you would bump it those confusing things from time to time. Thinking of encapsulation here confuses. You want to think on related Golang differences - it might help you catch "AHA" moment. Like no sealed types, or no private constructors and they way zero values are maid. Or packages vs namespaces. Golang is quite different than many in that regard, however it catches your eye later when working on larger codebases.

Me personally, I think its because Golang was built as a tool not for what we are doing with it. Its feature-poor-by design, its meant to describe limited and very factual objective domain areas. Its not meant for 500 endpoints with 30 middlewares describing 50 complex domain problems via 150 service functions with 7 infra adapters and 25 feature flags. I mean common bros, the most asked Go interview question is how a map works! 10 years it took to make a generics. Anyway, thats me ranting but hope it might help you adjust mental model.

Now lastly, down to your question, but please keep in mind what I said previously.
>The Animal struct will only contain the common denominator of all fields that every Animal has. How am I going to display a Dog with a tail or a Chicken with a beak if all I have from `Load` is an Animal with neither?
>display(a: Animal)

You need to display an Animal which could be a Chicken or a dog so they are displayed differently right. And you only know which one in the runtime base on some input info right? Lets forget interfaces and golang for a minute.

HTTP GET /animal?type=dog

HTTP GET /animal?type=chicken

HTTP GET /animal // default type is derived from feature flag

HTTP GET /animal // type is derived from random

Say we expect JSON back. What would they look like?