You’re missing who you are talking to - this is the TTN forum, 99.999% volunteer run, with a mix of community, maker & professional users. TTI are the police, they invented it, it’s their baby, you need to talk to them.
LOL, having run a few integration webinars for TTN/TTI plus summer school and having my own code quoted back at me on the forum, lodged a number of issues when v3 was launched regarding the PF and was in the room when they announced the normalised payload system I think I’ve got a good handle on “the people designing it”.
During the v3 launch period there were compromises made to the PF size because it transpired that the majority of vendors just chucked everything in to one and got their marketing staff to write it for good measure. There are plenty of topics on here about vendor PF’s not working, one as recent as a couple of weeks ago that I answered/fixed with my WOPR.
Apart from not being guaranteed to run, which admittedly is very rare, it also suckers people in to only saving the numbers rather than saving the raw payload and decoding locally in the language of their choice - quite a few people can’t translate an imperative language (JS) in to another imperative language (PHP, Python, Perl and others that don’t start with P) or vice versa - so it’s easier for them to decode locally in the language of their choice.
As well as delivering solutions, I do eat my own dog food - two days ago I saw a spike in a graph and it turned out an MCU had dropped below 0degC which was rather unexpected for even the far flung northern parts of England, minus temperatures outside, sure, but getting through the case and chilling the MCU - not something I’d anticipated. As I had the raw payload this was easily debugged.
TL;DR: Nothing wrong with using the PF as long as you have a backup in terms of the raw payload. If there are missing data types in the normalise schema, post a request on GitHub and haggle it out with the TTI dev team.