Performance Considerations

UCWAClient Usage

Because the garbage collector is non-deterministic in .net and HttpClient opens network ports, it's best to keep a long lived client instead of instanciating one for every call. see details
This is especially true for server side applications that might deal a great number of parallel threads running at the same time. The OS the code is running on might run into a port exhaustion issue (even if we dispose the HttpClient, the garbage might/will take longer than the rate of instanciation of new ports and will eventually run out)
For performances reasons the SDK is leveraging a pool of HttpClient to re-use those depending on which endpoint is targeted. That made the UCWAClient implement IDisposable.
For the exact same reasons, you should not instanciate and dispose the UCWAClient multiple times in a single sequence or use using blocks.
It's best to keep the client the longest you need it for the current code sequence and dispose it after.
You can also implement lazy loading patterns, static references and dispose the client when the AppDomain is being unloaded, however be careful of thread safety and performance impacts.

See the TestClient how it uses the library.

Authentication sequence

Because the Skype for Business infrastructure is composed of multiple sub servers/services, the product group chose to expose those as different OAuth resources.
This means any client library needs to go through multiple rounds of authentication/authorization to get a token for the different resources.
This can have an important performance impact if tokens are not cached (and revalidated before usage) per resource. This is something ADAL/MSAL does by default for you, so it is ok to call the AcquireTokenAsync multiple times for the same resources.
If you're not using ADAL/MSAL you should check the authentication library you're leveraging has the same behavior and implement it if it is absent.