Recently I needed similar behaviour in a UWP application where the API is different. The good news is this functionality still exists. It's just not always be obvious where to look.
The replacement for PhoneCallTask is Windows.ApplicationModel.Calls.PhoneCallManager.ShowPhoneCallUI.
The replacement for EmailComposeTask is the Windows.ApplicationModel.Email.EmailManager.ShowComposeNewEmailAsync method and the Windows.ApplicationModel.Email.EmailMessage class.
The ComposeSmsTask also has a replacement API. There is a significant issue using this on the desktop versions of Windows 10.
The replacement for ComposeSmsTask is the Windows.ApplicationModel.Chat.ChatMessageManager. ShowComposeSmsMessageAsync method and Windows.ApplicationModel.Chat.ChatMessage class.
This is a universal API and thus is available on desktop and mobile platforms. In the pre-release bits for UWP, this works fine on mobile but will crash the app on desktop. Whether this will be fixed before the official release is unknown. Note I really mean crash. There is no exception to catch and the unhandled exception event doesn't get raised. The process just dies in a nasty way. ApiInformation.IsTypePresent and such don't help because the API is intentionally available on both platforms.
This leaves you with no (good) way to support the feature and avoid the crash. Thankfully @aruntalkstech has the answer. You can use ChatMessageManager.GetTransportsAsync to determine if the current device supports any messaging protocols. If it does, it’s safe to call the compose API, if not then you should avoid it. For more information sample code, see Arun’s blog post.