From a semantic point of view, 'palettes' in tca is basically a sub-array of 'types'. But 'types' does not exist in flex at all. Also, the '--div--' thing from types in tca is done in flex on a totally different structural level, they have those 'sheets', so it is basically not possible to arrange flex fields within a form similar to how it is done in tca. That means, you'd probably have to make up a new syntax for palettes within flex form, making this stuff even more complex. Considering the fact that flex form definitions are incredible ugly to read already, this is not a path i'd follow here.
So, while it is true that flex forms have less freedom in arranging form fields compared to what plain tca provides, it is also rather ugly to implement this stuff and it would bloat this ugly construct even more.
With the refactoring of FormEngine in version 7, it is however now possible to do bigger changes on the TCA side, too. I have quite some ideas for a "tca 2.0" in my mind that could resolve the types and palettes sections (and the inline child tca overrides and the display conditions) of TCA in a much more powerful - but easier to understand and configure - way. Together with the fact that we're now able to on-the-fly-migrate TCA and flex to new syntax if we decide so, we do have the freedom to restructure bigger parts in the future.
But, this will take more time and I currently see no option to have a main TCA restructuring in v8, there is too much other stuff that is in the works already.
So, I'd be in favor of not touching those limits of flex forms at the moment, but instead handle this if we come back to a bigger rebuild of TCA structures later.