No, the chain is exactly that (in theory) - each of the pieces that SEQUENTIALLY are blocking boot. So
snapd.seeded.service [at]24.782s +6.387s means the next link in the chain should start at 31.169s: and that's
multi-user.target [at]31.170s, so it pretty much does.
So by removing snapd, for example, you'd boot up to 6.4s faster (in reality it would be less of an improvement than that, because snapd is waiting on other things, like internet access, so you'd need to fix that too. But if you cleared that out too then you'd save 6+s: I don't think any of the others are more than a few ms long).
That chain shows that systemd-journal-flush.service is the biggest problem in your boot time, at 17s. I THINK that's new to 18.04 (I know Debian doesn't use it). Basically it copies log files around on your hard drive, so aside from slowing boot in its own right it also blocks the drive from being able to do any other IO for services that would otherwise be starting up in parallel.
The systemd developers apparently fixed one piece of it in v240 (https://github.com/systemd/systemd/issues/10469). IDK what version 18.04 is using (
systemd --version will tell you) but the fix was "only" a year ago, so it's not going to be in that unless the Ubuntu maintainers backported it (which they should have, so you may well have it already).
You can apply the fix it yourself without much trouble. That said, I don't see how it would actually help: it's still a dependency of systemd-tmpfiles-setup.service, and that's the one that's triggering it on your machine. So I'm completely puzzled by that, I admit. It certainly won't HURT to do it, I just don't see it actually helping for you.
sudo pluma /lib/systemd/system/systemd-journal-flush.service and change the line that says
Before=systemd-user-sessions.service systemd-tmpfiles-setup.service to just
None of my machines are running this, so I'm very much just guessing here, and like I say I don't see how that would really help. But systemd is a mess, and "unexpected behavior" might as well be its slogan, so I'd say go for it and see.
If that fixes things, great. If not, some of the other ways to deal with it get you into much darker territory, and you probably don't really want to go there. But, one thing at a time...
Note that according to systemd, you should have a graphical login prompt (or autologin) about 31s after "userspace" starts, not 140s.
There are 3 pieces to boot: BIOS/POST, kernel, and userspace.
BIOS ends when GRUB (the boot menu) starts, and depends entirely on your hardware. Consumer PCs generally take anything from a few seconds to 20+ in this stage.
The kernel depends almost entirely on your CPU, but is usually just a couple of seconds even on old PCs.
The rest is userspace, which is what systemd is supposed to be reporting on. So 140s of total elapsed time is WAYYY longer than it "should" be.