Signing the installer is also implicitly shipping it with a checksum that verifies its integrity. The whole thing is handled by the OS automatically.
If you want to take it manual, then the best approach is likely to download Sigcheck and then use it like this:
Sigcheck both verifies the file is correctly signed (Verified: Signed) and then the -h parameter asks it to give the hashes it's signed for.
Then running the built in Get-FileHash PS function, you can see the two match.
Ultimately, a checksum is provided, it's just provided in a way that the verification is all done automatically. But if you did want to go manual, then this is how.
And this is more secure than the AppImage checksum, because we cannot prove the AppImage checksum is actually endorsed by Laurent in the same way we can with the Authenticode signature on the Windows installer, because the AppImage checksum isn't signed.
To compare against e.g the snap, you can view the checksums and signatures side by side; again proving its myself who actually submitted it.
The AppImage checksum, whilst not insecure or unreliable by itself, is absolutely the least secure validation option Joplin offers, because it's neither automatic nor signed. Most other releases are automatic and signed. To get a similar guarantee, not only would we need a checksum, but then we'd need a PGP signed file confirming the checksum of the checksum, which in short is exactly what Authenticode is doing.
Tl;Dr if you downloaded the Laurent endorsed installer, and a cosmic ray caused a bit flip that changed a single bit in the entire file, then Windows simply wouldn't let you run the installer at all, because it knows it's corrupted instantly. You'd get this:
(And this looks different to the previous error because the older versions weren't signed, so it wasn't the OS throwing the NSIS error earlier in the thread, but it is the OS throwing this error now).