Not all together happy with how this post turned out, but I've learned things that I didn't know before, so that's good.
For example, normally if two nodes (A and B) are connected to a switch which is on the downstream side of another device like your firewall, the switch will route packets from A -> B and vise versa without contacting anything upstream (from @Tedwin).
I decided to post my own answer with the good parts from the comments with @Panther Modern.
Use higher quality hardware. Since I'm using Netgear ProSafe unmanaged switches, I'm considering upgrading to something like Cisco. @Mike Pennington suggested the SG300 series, which I have researched before and found on Amazon for less than $200. @Panther Modern suggests Arista, Cisco, Juniper and Brocade switches.
Troubleshoot each piece independently and isolate the problem. I've done some of this, to the extent that I have isolated the general path, but in an environment where 100% uptime makes people happy and allows them to get work done, this can be tricky. But point taken...
Consider topology and where you have access to and how many users you have. These factors can influence your choices for gear and how you go about answering your questions.
Find good networking tools and use those to help troubleshoot your issue. pfSense helped a lot concerning traffic that passed through the firewall. I also learned about Robocopy for limiting traffic on the client. This tool works pretty well.
The three major differences between a managed switch and using Linux bridge interfaces are performance, port density, and features.
Most managed switches will embed some of their programmed functionality into specialized hardware. This is not true in all cases, but this specialized hardware will tend to outperform devices that are purely software based (at least for the functionality embedded in the hardware).
Second, if port density is of concern, there aren't many server systems where you can pack 12-48 ports into a 1U chassis, and of the ones I have seen they were designed to be a network device.
Finally, are the features. Managed switches will typically have features that either are not present on a Linux platform, not as easily configured, or may require additional CPU/memory resources that will further impact performance if you use them.
However, aside from the differences in the two platform choices, it sounds like you are setting up some sort of lab/test/dev environment. My primary concern would be that you should try to match your actual/production environment as closely as possible. Your Linux "switches" do not behave the same as your managed switches, so something you implement in the lab may act entirely differently when implemented on your managed switches.
Best Answer
Terms like "smart switch" and "managed switch" are terms invented by vendors. As such the exact meaning may vary from vendor to vendor.
In general "managed" switches are aimed at large proffesionally managed networks where people are prepared to pay substantial money for advanced management features and/or perceived reliability. They will typicaly have a serial console port allowing recovery from misconfigurations with minimal downtime.
At the other extreme "unmanaged" switches offer no management capability at all and are dirt cheap.
"smart" switches fill a middle ground. They have some management facilities and support VLANS but will often be lacking stuff compared to a conventional managed switch, for example:
Some vendors further divide their smart switches into multiple teirs, for example TP-link have their "websmart/easysmart" line which seem like total crap and their "smart" line which seems fairly decent.
Before buying any peice of networking gear I would suggest downloading and reading the manual. This will tell you whether it suffers from brain damage like no VLAN setting for the management port and whether it supports the features you need.