If that was true, then there wasn't a pressing need for 802.3ad. The fact that some vendors have made a feature work does not make it a good idea; basically if you look at what happens at layer 2, it becomes a royal mess, especially when you have an OS like FreeBSD that is abstracted so that it doesn't work with just a single type of networking hardware.
Almost all modern UNIX operating systems use abstracted networking stacks. Output traffic is handled through the route table, so the outbound load balancing that you are hoping to see by putting two interfaces on a single network ... just doesn't happen. The authors of the modern stacks know 802.3ad exists; it isn't 1989 anymore and RFC1122 stupidity is pointless. Making multiple interfaces work through a SECOND mechanism - in particular the "route it out the same interface" mechanism many people in your situation seem to expect - would require each packet to be looked up again in a different way, dramatically reducing throughput.
Multipath I/O on separate networks, preferably on separate switches and separate cards gives you a heck of a lot of resilience, a feature you just don't get if you try to stick it all on one wire.
The fact that the GUI used to allow you to do it and doesn't now is unfortunate; it
never should have allowed it. It yields an unexpectedly broken networking configuration in a way that you wouldn't expect.
Apple sums the topic up very nicely.
I am not going to follow up further on this topic. This is one of those things that's a matter of "what can be made to work" vs "what is correct." I too can make stupid things work. Non-ECC memory can work in a server. RAID5 can recover a 10TB+ filesystem. etc. Doesn't make it correct, and doesn't mean it will work reliably.