In later episode the allocator evolve and isn't a big chunk subdivided (if I remember correctly). There is no big advantage of having 1 giant allocation for everything, you can have one per system, or group them by livetime...
Remember that Handmade Hero is an example, you need to do or test what is appropriate for your game. There isn't a single right way to do thing.
Realize too that this decision was made very early on in the project and (from what I can recall since its been a while) this approach was actually the simplest approach for Casey at the time. It was simple because all he did was create a giant memory block and create a simple linear memory allocator which he could free all at once. Slight modifications were made to this scheme as he went but ultimately this structure made memory management pretty simple which allowed for smoother development. Later on, I actually think Casey implemented dynamic arenas as the need arose.
I think the biggest thing to take away from this is start with the simplest thing that works for you and work your way from there. If, while developing, you start finding that things might actually work better if you malloc a couple different arenas then there's nothing wrong with that. Your are correct that calling malloc more than once in your program is really not that big of a deal. The problem really comes when you are malloc'ing a bunch of little things every frame, which alot of programs (generally with the oop mindset) tend to do.
Thanks for assuring me on that, guys.
Yeah, it actually makes sense that Casey wanted to introduce memory management "systems" in growing complexity order, aswell as make things simple and transparent at the beginning.