It's because computers nowadays are running either on 32 bit or 64 bits processors. This is their "word" size. (32 is actually a double word and 64 a Quad word but you get the idea)
The largest integer representation truly natively supported by those processors is actually the size of a "word" according to their architecture. This is all fine as long as you stay within those bounds, but with the 256 bits EVM words you are way past that...
One example I like to use, 32 bits architecture were limited to 4GB of addressable RAM (before address expansion "hacks"), turns out that 4GB is 2^32. You cannot go above because you don't have enough bits to represent a higher integer number natively...
So to accommodate every architecture and keep the EVM running on 256 bits words , we must rely on non-native types that do require more operations but are able to handle size up to 256 bits (Big numbers can go way beyond that). Plus, it provides a uniform number format that is agnostic of the underlying architecture.
You may find that we can natively represent such numbers with floating point representation, but they do come with some precision issues that is not desirable in financial / precision systems.