I think it's always best to allow end-user traffic to use an MTU of 1500. Therefore when encapsulated the overlay network has to cater for this either by a larger MTU size in the encapsulated domain or by fragmentation/reassembly techniques. Since fragmentation is computationally expensive when performed in software, I believe that a service provider should define and use an MTU in the domain of the encapsulated traffic sufficient to allow 1500 at the user level and avoid any fragmenation, as you say 1600 for instance.
This won't significantly improve TCP performance in the steady-state, but it will avoid complications.
As a service provider you should be in a position to define the MTU of your network to the customer, and if you define it at 1500 nobody can complain, and you will reduce potential problems where for instance PMTUD doesn't work well for any reason or is slow to adjust or settles for TCP minimum.
The downside is that you will need to ensure that every Ethernet port along the way has an appropriate MTU defined. Some equipment may default to dropping jumbos (or mini-jumbos if you prefer). If you fail to do this then traffic may be black-holed somewhere along the route.
The worst case is of course when the service provider just leaves everything default and doesn't really actually have a defined MTU with the service offering.
I would caveat all this by saying I haven't ever worked on the radio network, so I don't know if there's any frame or cell structure there that would lead you towards a different end-user MTU for bandwidth efficiency.