I take "understand the wire protocol" to mean, perhaps, understand nature and shape of the communication between the client and the server.

Here's an "understand the wire protocol" story:

Years ago I dealt with a Customer's thick-client Win32 ERP application that back-ended into Oracle. They wanted to use it across a VPN. They naively thought bandwidth would be the major potential showstoppper and did measurement of bandwidth usage on their own. The app didn't throw around many bits so the Customer declared the test a success and spent the money on the VPN solution.

After the VPN was implemented they were unhappy w/ the performance of the app and asked me to take a look.

The application was built with individual SQL queries "bound" to many of the UI controls. Depending on what the user was doing, displaying a dialog might require 20+ round-trips to the Oracle server. The developers just assumed LAN latency and gave no thought to minimizing round trips.

Web devs are used to dealing with RTT latency today, but this was another time. The devs had no sense of how the wire protocol worked and ended-up making users like my Customer hamstrung into "solutions" like Remote Desktop / VDI.