Note that between Component Versioning – What is the importance? and Is rolling back code the only reason? Are there more? are quite different questions.
I will address the answer to the last question. So, to the question Is rolling back code the only reason? Are there more? The answer is yes. There could be as many reasons as purposes. While rolling back buggy code is a common one, I can think 2 more that I have seen quite often
The first one is long term support. If you have no control over systems that use your components, if you can not keep them up to update, it’s likely there’ll be segmentation by version. In other words, several systems adopting one or another version of the components.
While imposing the “latest version” policy is the easier solution for you, it’s not always the best policy for the consumer. Maybe, because it could be impossible (or unfeasible) to do.
Imagine Component_A-1.0 built to be compatible with JRE 1.5 or later and the same component Component_A-8.0 only compatible with JRE 1.8 or later (for whatever reason). Some systems might not be in a position to migrate to JRE 1.8 and yet want its old Component_A-1.0 dependency to be stable (at least for a reasonable period of time).
The second one is customized components. It’s not rare that once you have what you think is a very generic component, a new customer or dev team ask you for new features or changes. Here the versioning is not a mere semversion, but it’s still versioning and a much better one than bloating the code with loads of if_else statements.
Basically, a reason for versioning could be having different development lines for the same component, each of which with its own life cycle.