You fail to mention whether this application is Btrieve API based or SQL based. More useful statistics would be number of round trips on the network a second.
Btrieve API requests are synchronous. The application sends a request to the requester and waits. The requester passes it over the network stack and network to the server and waits. After the server processes the request it sends it back to the waiting client which eventually passes it back to the application. And for the Btrieve API the size of the packet is typically smallish based on record size plus a few bytes of overhead for the request. For a single client teamed NICs and many comm threads will have no impact because of the synchronous nature of the requests. They should of course help throughput when multiple clients are involved.
If it is a Btrieve API application there likely isn't any real bottleneck. As I hinted at above the number of round trips is the likely limitation. And the number of round trips has quite a few contributing factors and unfortunately fairly low on the list is the link speed. Yes gigabit can send and recieve more than 100Mb but it is not 10x because of other contributing factors such as "speed of light in copper" which is the same no matter what the link speed as well as the Winsock stack.
For Btrieve API if performance is critical they should be run locally to the database engine. Either directly on the server of via a Terminal Server session.
The SQL API typically sends buffers of information instead of single records so it is normally less affected by the above effects. But the SQL API also adds other overhead to the requests.