This is pretty spot on, so there's not much to add but a some somewhat disorganized thoughts:
Object storage and block storage are similar -- the difference is usually how they're accessed but isn't necessarily (ex. s3 via FUSE projects can be thought of as block storage). Some examples of the blurring of this line:
Hard drives are in the business of "block storage" -- you offer them a block of bytes (if you wanted to you could tell the hard drive exactly where to write the bytes, rather than using the file-based interfaces that are common), they put it on some sort of media (rotational, solid state, whatever), end of story.
Applications often only need a higher abstraction on storage -- not bits and bytes, but instead files or "objects". Most applications don't need the ability to access one or more bytes (in... a block) of an area on disk, they often only want access to entire files (roughly a 1:1 mapping with objects, with how 99% of the people use object storage).
Getting back to the question, block storage is usually interacted with via a completely different set of technologies -- iSCSI[0][1], NVMeOF[2], etc. The idea here is that you're talking to a hard drive on the other end, and it make sense to speak the language (or a language) of hard drives. Object storage is normally interacted with via HTTP. The expected/tolerated latencies using these different technologies are different orders of magnitude.
To rehash, object storage is similar, but seeks to up the level of abstraction and give you access to an consistent but opaque access to files. How is the object storage storing your files? You don't know and you don't care (probably) -- what you care about is how fast your HTTP request returns (or doesn't). This interface here is similar enough to reading and writing files locally but more importantly enables multiple applications to share the same storage without sharing the same hard drive. You can also write certain slices to files as well (this requires some more complicated locking and what not just like it would do locally).
I want to also note that there's a conceptual step between "traditional" block storage and "new age" object storage that others might skip over, that's distributed storage systems like NFS. It's NFS's job to present a file system that when changed, prompts a file system on a completely different machine to change in the same fashion. It's easy to imagine a simple way to make functionality work but of course reality is more complicated. Object Storage arises from the realization that you don't actually have to interact with a "fake"/shimmed version of the local filesystem that appears local but is actually remote -- you can just send a HTTP request over the internet to a machine asking for the file you want when you want it.
Here's a fun thing to think about -- is a database an implementation of object storage? You normally don't ship bytes to databases, you ship records (which you happen to decide the structure of) -- records are closer to files conceptually than they are to a "block" of bytes, even though at the end of the day the digital storage we're referring to is going to be bytes on a storage medium somewhere.
If you really want to get a good instinct for this, dedicate some time to skimming/reading through the Ceph documentation and you'll see how they layer the object storage (and other things) on top of a lower level "block" management[3]. The picture on the first page should be quite instructive.
You would use block storage more for a file system mount as a raw device (virtual).
There's overlap and many platforms support both close to interchangeably.