Using a configmap and overriding the command is definitely not the best way of going about it and not suggesting it as something you would use all the time. I only raised it because as an option it can technically work for some cases when you get stuck and don't have another easy way.
As an example, in OpenShift Online you can't do docker builds, so it can be convenient sometimes when using a third party product image from Docker Hub to customise startup. Having to build locally a custom version of a third party product image and pushing it back up to Docker Hub to be able to deploy it on OpenShift Online can be a pain. If you have full control over the cluster and can do docker builds in it, then not an issue as is easy to create a custom image.
Using configmaps like this isn't even restricted to overriding the command to edit in place config. If the application allows the location of config to be overridden by an environment variable, you could even map an alternate configuration file in from the configmap. This can be easier than having a custom command to try and edit the in place one on the fly. Alternatively you still also have the custom command and change options given to application to have it use alternate config from configmap.
The thing is that Kubernetes/OpenShift has these various options and so has a lot of flexibility. You may not use them, but still worthwhile knowing about them as can be useful to someone at some point.