Mike has posted a great answer, but let me provide some examples to illustrate the problems inherent in flooding all traffic.
Imagine you have a switch with 24 1000baseT ports (i.e. capable or running at 1000 Mbps - while not really achievable in the real world, for simplicity let's say we can). Ports 01-20 have computer/workstations connected to them, ports 21-23 are connected to servers, and port 24 is connected to the "internet gateway."
Computer01 starts pushing raw video footage to Server21. Server21 is capable of taking a full 1000Mbps of raw video footage and encoding it into a specified format and returns it in "real time" to the host that upload the raw footage. So Computer01 sends 150Mbps of raw footage to Server21 which then returns a 10Mbps stream of data.
With data being flooded, there is now 160Mbps of data being sent out all ports on the switch. No performance problem at this point, but Computers02-20, Server22-23, and the Gateway are all also receiving 160Mbps of data that they each have to process to the point of knowing it isn't meant for them and then drop the traffic.
Computer02-06 also start pushing raw video footage to Server21.
With five more computers, we have now hit 960Mbps of traffic being flooded out all ports. Again, this is below our 1000Mbps per second limit, but not by much. Again, most of the devices on the network will be receiving this traffic and have to process it to some degree.
With only 6 active computers and one server, we have almost reached the capacity of the flooded network. There is almost no capacity left for the remaining devices on the network, say if Computer07 wants to start an FTP download from Server22.
What happens when we hit that 1000Mbps limit? Which traffic doesn't get flooded? How does that impact performance?
Now imagine this on a fully populated 48-port switch (i.e. more computers/servers/end points). How about with a stack of 7 48-port switches? An enterprise network with 1000's of switch ports?
Or, take a mixed environment where you may have 10baseT, 100baseTX, and 1000baseT ports all on the same network. Computer01 above would fully saturate a slower device on the network all by itself.
Computer10 starts exporting a patient list from Server23 and downloading it as an XML file.
This may not take up much bandwidth, and while normally a network device will drop traffic not addressed to itself, this is not always the case. On this network, Computer 15 has been compromised and it now watching all the traffic it receives and now is able to also "download" the XML file containing the patient list as well.
To protect against this, you now require that all internal traffic be encrypted or protected by some means. This takes resources to develop, resources to verify everything is secure, and resources on the end points themselves to encrypt/decrypt everything.
So, back to your original question, "Why doesn't it always do this if it can, since it would be faster than doing a look up in a table?" Most switches utilize specialized hardware that does these look ups very, very quickly. This isn't measured in microseconds, but rather in nanoseconds (and won't reach the double digits at that). It is also not tied to CPU or memory resources.
Compare this to the amount of processing required by each station as it inspects and drops all the unnecessary traffic (also typically measured in nanoseconds, but it needs to be done by each device and not just the switch).
Or the time it takes to time out and re-transmit a frame when the network is congested (which may be measured in seconds).
Or the time it takes to establish some sort of encryption between each set of two devices that want to communicate in a secure fashion (which can easily introduce microseconds of delay). In addition, this may require additional traffic (such as a SSL/TLS exchange, etc).
Flooding all traffic is simply unfeasible on a network with more than a handful of devices.