Standard services are pretty fixed in their behavior. Extending the service with the custom characteristic is probably your best bet if you want the data to be in the same service. The main differences between a custom and standard service/characteristic are:
UUID size from 32bit to 128bit
Name of the constants/variables is different when generated by the IDE for the API usage
Doesn't get included into the standard service event handler (iirc).
The custom characteristic should have code variables/names being generated by the IDE, they just have a slightly different naming convention than the standard characteristics.
The custom characteristics are generated as can be seen in BLE_gatt.c, but no file contains the defines for the index and the handle as BLE_custom.h would have.
It isn't included into the CYBLE_UDS_CHAR_INDEX_T, so the write commands can't be handled in the same way as the other UDS characteristics.
When a read or write command is send to the custom characteristic, the UDS read or write callback isn't called, but the standard callback is used.
To me, it looks like the characteristic is shown as part of the service, but is technically excluded from the service itself.
All the implementation still needs to be handled like it is a custom service, so there is no advantage to including the characteristic to the UDS in terms of developing the software.
Yeah, unfortunately I'm not really surprised by that. From what I've seen, the custom services are more of a "low-level-access" kind of implementation rather than a useful API similar to the standard/defined functions.
There is nothing to stop you from implementing code that mimics the structure of the UDS API/code file generation however, so once you setup the constants in a file and include it, it would behave similar (less the event handling )
For my own project, I found it easier to create a new service than to use an implemented one, but to each his own...