All services are "disabled" by default; "enablement" is opt-in.
Is it correct?
Yes, in that if you create a unit file on disk, you still need to run some commands for systemd to learn about the new unit (systemctl daemon-reload), to start it right away (systemctl start ...), to request that it's started on boot (systemctl enable ...) or to enable and start it at the same time with a shortcut (systemctl enable --now ....)
But when you install a package that includes systemd units, the package will typically run most of these commands for you as part of their post-install scripts.
After I run
sudo apt install openssh-server
why is sshd automatically run?
So the package's post-install script is enabling it and running the package after it's installed.
You mentioned you're on Lubuntu. Debian-based distros (those typically using apt-get or apt) such as Debian itself, Ubuntu, Lubuntu and its other variants have traditionally started and enabled packages right after installing them. Their philosophy is to ship sane and "safe" defaults that allow starting a service and making it useful out of the box. (By "safe" sometimes that means not accepting connections except from localhost, or sometimes restricting authentication to strong forms of authentication only, like key-based authentication.)
Red Hat-based systems (RHEL, CentOS, Fedora, I think SuSE too) typically do the opposite and require the administrator to explicitly enable and start a daemon after installing the software packages for it, so they'll have a chance to review its configuration before it's brought up for the first time.
systemd created a mechanism to wrap around enablement and initialization, and it's one that takes into account the distribution-specific policies in this regard, which is called Presets.
That mechanism allow packagers to simply call systemctl preset ... from their post-install scripts, so they don't need to worry about the specific policies of the distro.
Debian-based distributions will push a *.preset file that has the line enable *, which will implement their policy of enabling everything by default, while Red Hat-based distributions ship a *.preset file with disable * to implement their preference.
Beyond making the mechanism behind this distro-specific setting uniform across distros, systemd Presets also offer an easy and uniform way for administrators to customize those settings, selecting different presets for specific packages or wholly overriding the distribution's original choice.
In practice, Debian-based distributions end up not using systemctl preset directly, instead they ship a small wrapper around it, which is what they use in their packages' post-install scripts. The reason for the wrapper is to record the enablement mode of a package when it's uninstalled, in order to preserve it in case the package is installed again in the future on that same host. The systemd preset configs still work as usual on these hosts, so this small detail can for the most part be ignored.
