Yes, all the convolutions you mention could be combined into a single one for final implementation.
However, it makes sense to break the individual requirements apart in the user interface. A raw convolution kernel function is difficult for even someone trained in such things to mentally derive or convert to the time domain (in this case actually space domain) effects. You want several knobs that adjust things in human conceptual space, then have individual or combined convolution kernels created under the hood.
The reason for not combining the convolutions of several effects is more likely due to software structure. Especially with a larger application that has a plugin architecture, each plugin needs to do its thing independently. There would have to be special resources in the main app that would allow plugins to add their specific modifications to a global convolution kernel. And, that would only work in the case of linear effects, which many aren't. The single global convolution would also need to be quite large, possibly executing slower than a few smaller convolutions successively. The global convolution engine could look to see how far out the non-zero data extends, but that adds more complexity and more runtime decisions.
All that said, sometimes effects are combined. I do this in my own software on brightness mapping. I have several user-visible controls, some linear some non-linear, but much of the result ultimately gets converted into a set of lookup tables. I haven't implemented sharpening yet, but I probably will fold that into the output filter. That is currently a convolution used for anti-aliasing when writing to lower resolution.
Added about brightness mapping
My software allows for several ways of controlling linear brightness mappings, and multiple non-linear mappings that are combined. The linear mappings are ultimately converted to a Y = mX + b format internally, despite a number of ways of effecting that from the user interface. The non-linear mappings are defined in terms of logs and exponentials, which would be very time consuming to compute each pixel, or each individual contribution to the 2D filter for each resulting pixel value.
There is some computation that needs to be done on each color value as a whole, but most of the linear and non-linear mappings are ultimately combined into three lookup tables, one per color. I represent the raw image internally with 16 bits per color per pixel. For a modern computer, three lookup tables of 65536 entries each is no big deal. With that relatively small emount of memory, any arbitrary mapping from input intensity to output intensity can be represented. The tables are loaded by doing the log, exponential, and other calculations. When the actual pixel mappings take place, all that just becomes a lookup.
Three lookup tables per color can only handle certain things. Some mappings work on the whole pixel color globally and can't be separated into independent R, G, and B mappings. Still, many can, and the lookup tables combine any number of them conceptually applied in series and laboriously calculated into a single lookup.