The receiver has to look at the Ethernet frame to decide its contents, which might be DECnet, Appletalk or many other things -- Internet Protocol is only one of many protocols running on top of Ethernet.
When Ethernet was being designed, it wasn't obvious at all what protocols might exist in the future, and the winner-take-all effect wasn't obviously so large. A key goal of Ethernet was ubiquity -- in order to be cheap it had to be everywhere, and so it was designed to be completely neutral about its contents.
It's also a fundamental idea in the separation of the layers: code for each layer does not look inside the contents, it has a label on the outside which says what it contains along with whatever is required for addressing. For example the Ethernet frame might say "contains IP". Inside its payload, the IP header has a label which says "contains UDP". The UDP header says "contains DNS" (inferred from port number). And the DNS program is responsible for deciding what to do with that. If you don't do it like this then you duplicate at least a little of the code of the upper layer in the lower. (Or, required some kind of mechanism for the lower layer to ask an upper layer "is this packet one of yours?".) And, worse than that, this then limits the lower layer to working with upper layers which the lower-layer implementer knew and cared about. I guarantee you the Ethernet designers didn't know about IPv6, and it's the separation of layers which permits the easy development of new protocols.
Those who were obsessed about a few bytes generally wrote their protocols raw on top of Ethernet, essentially using it in the way we might use UDP. Most of those surely regretted it and converted to TCP or UDP later when they needed a facility such as ports or reliable ordered two-way byte streams, or indeed, multi-hop transport.