It is almost difficult to limit UML 1 for the following reason: almost all available charting tools have been implementing UML 2 since ancient times. So, every time you draw a construction, you need to manually check if it is already available in UML 1.
Step 1 to 2 was largely due to the demand for software development called MDA (Model Driven Architecture) about 10..15 years ago. It was about creating software directly from the model. To support this, all elements of the model were defined through some formal semantics. In addition, some models and diagrams have been expanded. Sequential diagrams have been enriched to control structures for expressing control flows. Component and deployment diagrams have been expanded.
Now, not to mention that it makes no sense to return to UML 1, I read from your question that you need to set priorities. This makes sense, since the definition of UML (1 as well) 2 is quite lengthy, and you do not want to study every detail. So here are some tips:
With object-oriented technology all over the world , class modeling is a central concept. Thus, you should be familiar with classes, associations, aggregates, composition, inheritance, attributes, operations and their parameters and results, the visibility of methods and attributes, abstract classes and methods and interfaces.
Class objects change their states by applying their operations. The central, and sometimes underestimated, type of model is the state model . Here, UML offers two partially redundant models and chart types: state and activity models. You should get to know one of them more closely - switching to another should not be too complicated.
Most UML users are very fond of using case modeling . I do not, because these use cases, as a rule, have neither significance (if you are limited to the purpose of use and the executors) or structure (if you begin to document system data and functionality with your use cases). But the rest of the world will only accept you as an UML expert if you know them, so you cannot avoid them. Before using them widely, think about how to achieve the DRY principle (do not repeat yourself) when describing a system using precedents.