question

Couple of things.

The WAP is useful as soon as you want the ADFS farm to be used externally. Users who are trying to reach the FQDN of your ADFS farm while connected to the Internet will resolve to the IP address of the WAP or the load-balancer in front of the WAP servers. Whereas internal users will reach the FQDN of your ADFS farm using the the IP address of the ADFS server or the load-balancer in front of the ADFS servers. There is a split-brain DNS configuration to make it work (see section DNS requirement here).
When a user goes through a WAP server to reach ADFS, the user's request will be tagged and the ADFS servers will be able to use that information to:

• Create custom access policies (for example blocking access from outside for some users, or groups, or trigger MFA because the users is outside etc.)

• Use different authentication policies for external users (for example if the user is internal, ADFS will do Windows integrated authentication - like SSO with Kerberos, but when the same users goes through the WAP, Form Based Authentication will be used, or certificate, or Azure MFA as a first factor for authentication etc...)

• Throttle the authentication attempts to prevent password sprays or other password based attacks to lock out your users internally, they will be block at the ADFS level and will not impact your internal users (features called Smart/Soft extranet lockout policies).

  
  

None of these aforementioned features require to have your WAP domain joined. As a matter of fact, if you are using WAP only to publish your ADFS, you do not need to domain-join it. However, if you want to use your WAP to also publish Kerberos-based application externally (using protocol transition) then the WAP has to be domain-joined (basically to be able to do Kerberos).

You cannot replace the WAP with a NetScaler. It is not a supported replacement (to be a supported replacement the solution has to implement the following: MS-ADFSPIP: Active Directory Federation Services and Proxy Integration Protocol and as of today, I am just aware that F5 BigIP did it). Unsupported solutions will not enable ADFS to detect the query is coming from outside and the features mentioned will no longer work. It might also break some authentication method depending on how they are implemented (such as certificate based authentication or device authentication for Windows Hello for Business with certificate trust). But you can use Netscaler to load balance the traffic to your WAP servers and to your ADFS servers (there would be two different virtual IP one for the external WAP and one for the internal ADFS).

Regarding your specific scenario, I am assuming this 3rd party applications are trusted (federated) with your ADFS farm (they are relying party trusts in your farm). Then if your users are expected to access these applications solely when they are connected on the corporate network (or when they are connected via VPN), then you might not need a WAP at all. But often users also need to access the apps when they are not connected on-premises. And it seems to be your case as you would like to trigger MFA when these users are externally connected. So in that case you would deploy a WAP that you can publish with Netscaler. And then configure Access Policy to trigger MFA when the condition you pick are met (and it could be a combination of conditions such as user is connected externally and member of a specific group).