How user data is encoded is entirely outside of TTN - you are welcome to do anything you want to it before it is encrypted, packed into a LoRaWAN packet and checksummed, and the same after it has been verified, extracted, and decrypted and presented to your consuming software, without changing TTN.
Keep in mind however that LoRaWAN adds a lot of overhead on top of application data, to the point that shorter packets are mostly overhead with very little application payload. If your application can tolerate it, sending longer packets less frequency is more efficient.
Except that how long a payload can be sent depends on the range from the nearest gateway, which determines what data rate (spreading factor) is used. In Europe long time duration packets are allowed, so to a limited degree even the super-slow long range SF12 can be used.
But in the US we can’t use spreading factors larger (longer) than 10 for LoRaWAN, because at SF11 the LoRaWAN overhead itself would not fit in the packet duration limit.
This may mean that an application ideally chooses what packet to send (vs how often to send) based on the spreading factor currently chosen by the adaptive data rate (ADR) algorithm.
gain more time for paid or not paid TTN version. For example, we have in the link
You were given a somewhat false distinction there. No organization “owns” the airwaves, they are shared resource. Primarily what the TTN fair usage policy concerns is using the capacity of the gateways owned by other members of the community - if you are using a private network, either via TTI or some other solution, you are using your own gateways or perhaps paying to use someone else’s.
At that point the legal and technical limitations remain
The legal limitations vary from place to place.
The technical limitations include the degree to which the design of LoRaWAN as a protocol matches some needs and mismatches others. The range of options there includes not only the TTN public LoRaWAN network vs private LoRaWAN networks, but also private networks that use LoRa in a way different than LoRaWAN uses it, networks that do not use LoRa, networks that use other frequencies, etc.
Likely you should spend some time and gain some practical experience with the existing offering before you jump into building an alternative.
No decision is without tradeoffs, if you make a change to improve one thing, you almost invariably make something else worse. And once you change anything about the network scheme itself, you loose the ability to participate in the public network.