Switch – Firewall with layer 3 switch or without it

Unmanaged, is a basic switch, just passes packets from A to B.
L2, will do basic segregation based on things like vLan, and usually will do QoS, and might do other things like GVRP. This is most useful when used in conjunction with a L3 core switch, or a router that fully supports vLans.
L3, will do routing between different subnets on different vLans and might do basic traffic shaping (depends on manufacturer and model). It may support ACLs, but it's not terribly common. This is most useful as a switching core in a semi-complicated network.
L4, is basically a simple router with a ton of ports. These allow for very complicated networks, and the price reflects it. Usually these have every feature mentioned above plus all the features commonly found in cheaper (business grade) routers.

Edit:
Generally people use vLans to separate different types of traffic. It's common for VoIP phones to use a different vLan for voice traffic than "normal" network traffic. Also it's common to separate SAN and Management networks from the rest of the network. Particularly with the management features it's convenient to have a L3/4 switch with ACLs so that only Admin computers can access the Management controllers (iLO/iLOM, network connected UPSes). Before anyone launches into a "don't you trust your employees" argument, sometimes it's better to just know who can/can't access things.

Also you can use vLans to make a visitors' network. That way certain ports (in conference rooms, waiting rooms, or public areas) can be used by guests/visitors without letting them on your network.

Most of these things can be accomplished with a L2 switch and a vLan aware router. However going this option will reduce your vLan switching fabric to the links to the router; which may not be enough bandwidth (depends on your network and requirements).

One useful benefit of "L7" like haproxy is being able to use cookies to keep the same browser hitting the same backend server. This make debugging client hits much easier.

L4 balancing may bounce a single user around on several backend servers. (which in certain cases may be advantageous, but in a debugging/profiling sense, using "L7" is much more valuable.)

EDIT: There's also a potential speed advantage of using HTTP balancing. With keep-alives clients can establish a single TCP session to your balancer and then send many HITs without needing to re-establish new TCP sessions (3-way handshake). Similarly many LBs maintain keep-alive sessions to back end systems removing the need to do the same handshake on the back end.

Strict TCP load balancing may not accomplish both of these as easily.

/* FWIW: I wouldn't say "L7" or "L4", I would say HTTP or TCP. But I'm a stickler for avoiding using the OSI to describe things it doesn't match up with well. */

I think fundamentally if you're not sure what to deploy, go with what feels simple and natural to you. Test it (use apache bench?) and make sure it works for your needs. To me HTTP LB is more natural.