You're mixing two different things.
One is HEC vs plain TCP for receiving data from sources. And here HEC is much better choice - its performance is great (whereas plain TCP inputs have its share of problems as I remember), you can create many different HEC endpoints on a single port and differentiate inputs by the token, you can dynamically overwrite metadata and add your own fields with HEC and so on.
Another thing is your own HEC-supplying "forwarder" vs. Splunk's UF. It's more tricky. Sure, you can get - for example - rsyslog instance to read files from disk and push events via HEC to your Splunk installation. It might even have some advantages over monitor input in UF (you can do much funky stuff in rsyslog that you can do in UF like filtering and advanced manipulation). But it's not a standardized approach, it will be harder to debug and you won't get support for such installation as easily as asking a question about UF here on Answers. And splunk's internal S2S protocol (the default mode of sending data from UF to indexers/HFs) is also very efficient.
So in general - HEC as input is a very efficient thing and can be used for relatively high throughputs. And you can put a load-balancer in front of your Splunk infrastructure if needed, you can offload TLS operations to an external solution - it's a standard HTTP after all. But should you replace UF... well, that would need more consideration.
