A few things. (1) If the payload is shorter than the key length (e.g. 128 bits) then crypto is actually really strong (and easy). For long payloads, you need to work a lot harder. (2) For doing a public key handshake, you can do it without a huge packet using one of the elliptical curve algos, but for any public key handshake you need a reasonably short duration of the handshake in order for it to be adequately secure. That's a bigger challenge than the data size. Low power LTE Cat M1 or NB-IoT systems aren't any better at practically serving low latency sessions than most LPWANs are. (3) "secure elements" should be called "insecure elements" when the items they are installed in are remotely operated in public environments. (4) Carriers tend to use TCP/IP with LTE, which is more of a limitation than a benefit, because it prevents any manner of broadcasting. There are a lot of applications that can be low power if they are broadcasted, but will never be low power (or easy) via TCP. (5) The direction LTE has gone, in my opinion, makes it undesirable for a lot of applications. It is nice for low-volume monitoring applications. So in a sense I think LTE as a LPWAN is really the great solution for niche use-cases.

Your claim (1) looks a lot like hubris to me unless you're imagining a product that sends only a single payload during its lifetime.