In theory, there's no reason that we couldn't just use Ethernet MAC addresses to communicate on a LAN segment.
In fact, as someone mentioned upthread, that's pretty much the way it works: your laptop sends out an ARP request saying "I'm 11:22:33:aa:bb:cc, my IP is 10.10.10.20 - who has 10.10.10.10?", your NAS responds to say "I'm x.x.x.10 and my MAC address is aa:bb:cc:11:22:33!". Subsequent packets between your laptop and the NAS will have the appropriate MAC address in the Ethernet frame header.
So, why do I say 'in theory'?
Well, in practise, the Ethernet standard provides a mechanism by which devices can locate each other on a network segment; this is useful, because it means that devices that aren't participating in a network conversation don't have to listen to it and that switches can track what physical port each device is connected to. It reduces the amount of network chatter on a segment and increases the overall throughput of the network.
Unfortunately, there's a lot of great stuff that's provided by the TCP/IP stack that Ethernet doesn't provide, and with good reason. These missing features would need to be implemented by the developers of each networked application, which is a hell of a lot of work to go to when every modern operating system has, at the very least, a TCP/IPv4 stack and probably also has an IPv6 one.
There's also the simple fact that simple network often don't stay simple - sooner or later you're going to want to connect your LAN to the internet or to another LAN; IP is routable, MAC addresses aren't.