I think that good cases both for an against optional fields have been made here and elsewhere.
To add to them, I also think that the Python experience shows the value of optional fields for function call type communication. It can give an API more expressiveness and make more explicit how it is intended to be used correctly. I agree that it can also add a lot of complexity, but at least for services that complexity may be worth it. I think it depends on how the majority of ROS users are creating services. Are they being used as remote procedure calls, or are they more often used as two-way or pull-style pub/sub communication (e.g. pull a copy of the map only when wanted)? If it is the former, then perhaps optional fields should be considered for service definitions. Of course, that raises the prospect of reducing the compatibility between .svc and .msg definitions, which I think is probably not desirable.