Because the 3rd panel looks better when you have dozens of physical properties to track. It also makes retrieval easier because you can get all the physical properties at once, instead of having to read every line.

For an example that small it doesn’t matter, but for something larger it could become a performance benefit.

since that shit makes it harder to read

It makes it harder to read the individual lines, but makes it easier to read them as a group, so you won’t have to read as many lines on your day to day.

I would guess that it has to do with making it easier to parse. The indents won’t matter very much, but the parser sees "physical = " and knows that a property named physical is being defined. What is the value of that property? Well, there’s a “{”, so the value is an object. And the value of that object is everything up until the matching “}”. If you have a structure more like panel 1, then it’s harder for the parser to know when the value of orange.physical is complete. There might be a [orange.physical.texture] section somewhere, for example.

For programming languages that make use of {}, the reason is (almost always) scope.

Take for instance this:

for i in 0..10
do_thing();
do_other_thing();

compared to this:

for i in 0..10 {
    do_thing();
}
do_other_thing();

The intent of the first one is unclear. In the second one it’s clear you should loop do_thing() and then run do_other_thing() afterwards. The indentation is only for readability in the above though. Logically there would be no difference in writing

for i in 0..10 { do_thing(); } do_other_thing();

Languages that use indentation and line breaks for scope look more similar to this:

for i in 0..10:
    do_thing()
do_other_thing()

A good way to feel that for yourself is by programming a little program in Assembly and C.

Make sure the program needs to loop a bit and perhaps also require some if/ else logic.
A simple one would be to read a 1000 integers and return the sum.

In C, you would do something like:

int MAX = 1000;
int accumulator = 0;
int counter = 0;
while (counter < MAX)
{
    accumulator = accumulator + value_at_next_memory_location_by_counter;
    counter = counter + 1;
}

In assembly, you would go (writing pseudo, because I have forgotten most assembly stuff):

set reg1 = 1000 // For max value
set accumulator = 0 // just choose a register and consider it an accumulator. older CPUs have a fixed accumulator and you can only operate on that. I am not considering that here
set reg2 = 0 // For counter
tag LOOP:
set flag if true reg2 < reg1
jump if false -> END
move from memory location @counter(reg2) to reg3
add accumulator reg3
add reg2 1
goto -> LOOP
tag END:

---

I also realised that you could just try using C with goto instead of any loops and would realise similar things, but I’m not in the mood to rewrite my comment.

---

In conclusion, it is easier to understand something like BASIC, if you haven’t been introduced to other languages, but these {} structures end up making it easier to catch control flows at a glance.
That’s also the argument I use when telling people to have opening and closing brackets of the same level at the same indent, while people prefer stuff like:

if {
...
} else {
...
}