Some people are using some of the powerful new SysMLv2 usage capabilities just because they exist without good reason.
As it concerns parts:
There’s no good reason not to create a part definition level element first. Part usages are then simply EITHER directly typed by a part definition OR then have the option to adapt the definition "on-the-fly" using the new SyMLv2 capabilities in context if required for that specific context.
If you just create part usages you may also be missing out on the opportunity to connect to reuse mechanisms, unless you are subsetting other parts for that, in which case you might as well specialise a part definition anyway!
Webel's rule of thumb:- Use part definitions to capture any commonalities across entities, including default values (where values here importantly does not just mean primitive values but can be any usages).
- Use part usages to capture context-specific variations (including context specific value overrides).
- A part usage that does not have a part definition is considered “orphaned” and not fully resolved. You can use them initially untyped as part of your modelling process, but they should not remain orphaned, and indeed you can use that to track which elements are not yet fully specified.
- If you don’t do it that way, you can end up with defaults "stuck" in your part usages and then have to bump them up to definitions anyway (assuming you are using them at all), which is messy and fragile.
Confusion about this has also arisen because of one older modelling “instance first” approach that was used in SysMLv1, and had some history in software engineering and UML2. The idea was that you identify first, sometimes just by name, untyped elements of your system and their attributes; you’d
then bit by bit use them to identify the types and upgrade them them to have types. But it really wasn’t so beneficial in practice in good tools. In MagicDraw/Cameo you could simply type in :MyType with a preceding colon and it would create an anonymous element that was typed. Better, easier, faster.
Finally, too much to go into here, but a part usage is not an “instance”, it is a generator of one or more instances that are in memory in something like the Cameo Evaluation Plugin or the Simulation Plugin, and there are good reasons if you are simulating to have part definitions that can't be instantiated and reserve part usages owned directly only for a package for those entities that can be executed.