This is mostly speculation, but some of this goes so far back that even those amongst us who once knew, might not remember. In some cases, no one might ever have known why.
1. Why does the speed of citycars is multiplied by 16 to be saved on the pak?
Not that we need a citycar faster than 4095km/h, but it's just strange.
The only reason I can think of is to allow speeds lower than 1 km/h in the pak format.
2. Why does the cost of signals does not take account the cents, but all the rest do?
Most likely because whoever wrote the signals didn't need cents at the moment and didn't think to check how other things did it.
3. Why topspeed on bridges is uint16, but for tunnels, ways and way objects it's sint32? It does not even make sense to have negative speeds.
Integers are signed by default in C and C++. Compilers yell at you when you mix unsigned and signed. Since values are never going to be high enough that it matters, it might have been easier to use signed ints than unsigned ints.
5. And why maintenance is uint16 for vehicles when for the others it's uint32?
Vehicles don't have maintenance, they have fixed_cost. They are not the same, were not made at the same time (maintenance is way older, I think), perhaps not by the same person, and perhaps without having the older one in mind when implementing the newer.
6. Why distributionweight for trees is uint8, but for the others it's uint16?
Trees had distribution_weight long before at least some of the others even existed. It is possible that by the time the others came around, a larger range of values was seen as ideal, but not important enough to bother altering the existing format of trees.
11. Why parameter cost for ground objects is sint32 when all the others are uint32?
Maybe some of them are so ugly that the local government will pay you to remove them?
12. Why all parameters for fields are int? Is it not a waste of resources? I mean, 255 for number of fields is already quite impossible. I guess it's unnecessary to expect anything bigger.
Memory is not really a constraint for besch-types (except images, where the limit trying to restrain memory usage was contested and defeated). However, I can't see any field fields that are plain ints. Some are uint16, but I don't think farms covering more than 16x16 tiles is too far-fetched.