The two package types have different intended use cases. You'll know which one to use by asking yourself one simple question: "Am I packaging for internal processes or for a distributed app (e.g. AppExchange)?" If it's internal use only, use an Unlocked Package. If it's intended for AppExchange or other distribution channels, it's a Managed Package, even if you intend to use it internally as well.
The new model for managing metadata is that the "source of truth" has changed from a single org to a single repository. This makes it easy to keep orgs (production, sandboxes, etc) in sync. The "unintended customization" quality of Unlocked Packages is not a bug, it's a feature. Don't use Managed Packages unless you intend to make a distributed app, and don't try to mix the types, as that is not the intended design.
You should not be building two different packages. The software development lifecycle (SDLC) is identical for both types of packages, so the only reason to choose one over the other is for the intended consumers. Unlocked Packages (2UP) are for subscribers to manage their own internal metadata, and Second-Generation Managed Packages (2GP) are for ISVs to develop and deploy apps on the AppExchange or by other means for subscribers. The main differences between the two are that 2UP do not offer Intellectual Property (IP) protection and cannot be listed on the AppExchange, similar to a First Generation Unmanaged Package (1UP), while 2GP packages restrict certain kinds of component deletion that 2UP doesn't care about, similar to a First Generation Managed Package (1GP).
It appears you're under the impression that 2GP development involves installing the package. This is not true. The Software Development Lifecycle (SDLC) is identical for both types of packages. You're just missing some configuration. First, if you haven't already, enable Dev Hub in your production org. This is your subscriber org if you're a client, your Partner Business Org (PBO) if you're an ISV/OEM, or a Developer Edition org without a registered namespace for other purposes (e.g. hobby development, independent consultant, etc). The latter type of org has very limited resources compared to a paid org, though. We'll refer to this newly configured org as the Dev Hub Org (DHO). You cannot use any existing First Generation Managed Package (1GP) Developer Edition org as a Dev Hub, though you can use this org for the namespace it carries. Also make sure you've enabled the appropriate permissions for your developers to use the packaging features.
Next, link the namespace in the DHO. Go to the Namespace Registries tab in the org, and click on Link Namespace. This opens a window for you to log in to the Developer Edition that holds the namespace for your packages. Note that one namespace can be shared across multiple DHOs, and multiple namespaces can be linked to a DHO. Further, multiple packages created in the same namespace can be installed in a single org if there are no naming conflicts. Once you've done this, you can use the
namespace property in your
sfdx-project.json configuration file to create packages that belong to that namespace and, perhaps more importantly, create scratch orgs that have that namespace. As you're probably aware, multiple Developer Edition (DE) orgs can't share a namespace. Scratch Orgs can share a namespace, which enables them to act like a namespace-bearing DE org; development in this kind of org closely mirrors how development in 1GP used to work, but without all the conflicts and overwrites possibilities by multiple developers working in a single org.
The main difference is that instead of having a permanent org you use to develop in, and can potentially break by accidental metadata deletion, Scratch Orgs with a namespace are easily deleted without any consequence to the package. It becomes much harder to accidentally break your Packaging Org. And with 2UP and 2GP, you can even create alternative branches as a kind of ultimate do-over. However, upgrades are allowed only between versions with a common ancestor. See the documentation about ancestry.
So, what does the SDLC look like for 2GP and 2UP? Once you've set up the appropriate configuration in your DHO, the process is fairly straightforward. First, create a Scratch Org. Then, use
sf force source push to deploy the metadata to the org. After that, create a new branch in the repo, as you would in any standard SDLC setup. Any changes you make in the Scratch Org can be retrieved with
sf force source pull. When you're satisfied with your changes, use
sf package version create to create a new version, and optionally promote it with
sf package version promote. This promotion allows installation to production orgs. Note that this is different from 1GP, where you had to choose to "promote" ("Release") at the time of upload. After everything is done, you finalize with the appropriate commits and merges in the repo. The Scratch Org can then be deleted, and developers can work on new features/bugs.
Note that, unlike 1GP "Beta" versions, a 2GP version can be promoted at any time, and once installed, can be upgraded to later versions regardless if they are promoted or not (assuming the org allows unpromoted versions). Also notice that no two developers will ever conflict metadata in their respective Scratch Orgs, which is another major benefit over 1GP. Any conflicts that happen will necessarily occur in the repo itself, which is far more manageable.
As far as "unintended customizations" that 2UP may cause, that's an intentional design choice. Before 2UP, admins and developers alike could cause all kinds of unintentional customizations without any warning. In the new model, all changes should come from the repository, which is the source of truth. Unintended customization is now anything done in a production org to bypass the process. While it does take more time, it provides better safety in case of various "oops" moments that tend to happen from time to time. You should see 2UP not as a threat to your org's metadata, but rather as a way to protect it from accidental changes that originate outside the prescribed process.