[See below for correction...]
I can confirm that withdrawing the Firewall policy from the group solves the problem.
So, to summarize...the problem appears to be that if a Firewall policy is applied to a given group, installing the 64-bit client (built with that group's policies) will take over and disable the Windows Firewall no matter what, even if the Network Threat Protection module is not part of the client installation.
In our case, withdrawing the Firewall policy isn't a big deal because it was only there for testing purposes, but others who have a mix of clients (some using NTP, some not) in the same group may need to segment those clients in order to take advantage of this workaround.
Correction: While withdrawing the firewall policy solves the problem with the Windows Firewall being disabled when the SEP client is installed, it is only a temporary fix. It appears that as soon as the SEP client makes its first contact with the SEPM server, the Windows Firewall is disabled again.
I've even tried withdrawing the Intrusion Prevention and the Application and Device Control policies (both of which, I believe, also rely on the NTP engine), but the SEP client still takes over management of the Windows Firewall as soon as it establishes communcation with the SEPM server.
I apologize for the premature celebration...