[This Answer focuses on the reason why RAM at low address and ROM at high address, as the usual ramblings about the 640Ki border have been made in other places and amasse (*1)]
Why was the arrangement chosen with RAM in the first part of the address space?
It's the way Intel laid out the 8086.
The CPU starts execution at FFFF:0000, thus ROM had to be up there.
Intel learned from the success of the 8080 (and follow up Z80) as CPU for general purpose computers with variable programming (aka PCs). Here it is a great plus if entry points / vector tables can be set up and changed during run time. >The basic 8080 concept with restarts in low memory (Reset at 0000 and so on) works great for an embedded system. But for a computer it must be possible to change them from ROM configuration to some value the OS or a loaded user program needs. But at the same time, at least the entry for reset must be in some ROM (like) to make the machine boot at all.
Handling that problem for an 8080/8085/Z80 ended up in three solutions:
ROM at 0000h, each and every call to a restart gets first processed by ROM routines and at some point, if at all handed over to loaded (user/OS) code
ROM at 0000h, all calls (*2) get handed to a user pointer table via a jump indirect stub of various kind
ROM at 0000h, much like the first, but it gets replaced by RAM at runtime, enabling variable handling routines.
Any of these either limits functionality, adds processing time or needs additional hardware. Uncool.
For the 8086, its designers tried to break from these limits by separating Reset which always needs to be handled in ROM from all other exceptions to allow dynamic setup. Thus the CPU starts executing with segment FFFFh, offset 0000h while the vector table is located at Segment 0000h (*3) offset 0000h. As a result no hardware for switching out ROMs was needed, while at the same time the shortest possible code path for (variable target) exceptions was enabled. Lesson learned (*4,*5).
Bottom line: Never forget that the first microprocessors were not designed as core of a general purpose computers, but to make embedded controllers.
*1 - Can't hold my inner Nerd back: Come on, there has to be RAM and ROM in a system, and I/O (like video) is usually something to be put in-between. Heck, even the template for the IBM PC, the Apple II, made by the great Woz did it that way ... it even features a similar split 6:2 for RAM vs. I/O and ROM. For the PC it's 5:3.
*2 - Except Reset which still gets processed to some point in ROM
*3 - It's important to see this as segments, as that's not only the way it is implemented, but as well the (original) intended upgrade path for later CPUs.
*4 - In addition the concept was changed from restarting at the calculated location as the 8080 did, to address pointers (like Motorola already had) to be used with an indirect jump. After all, 4 bytes couldn't hold much code - already making it indirect resulted in a subsequent table and jumping twice.
*5 - Motorola as well changed when going 16 Bit. The location their a vector table from top memory down to zero