RCS is this old, mostly-forgotten unix tool that often gets denigrated by brogrammers and others on the modernity-in-tools treadmill. I use it a lot, for not entirely logical reasons, in places where others might use git. It's weird and idiosyncratic, and doesn't fit in with the way that more modern tools work. But, like this weird screwdriver, I feel that RCS is a good tool regardless.
One situation where I think RCS is the best tool, is for small one-off files that need versioning regardless.
I use it, for example, to version configuration files.
I'll check in the out-of-the-box default configuration as the first version of the file, and then make modifications.
It's really good for that, because you don't need to create a separate repository directory and then symlink in to it from /etc or whatever.
Some people create a git repository in /etc, but I feel like that puts pressure on to check-in more files than you need to.
I really only care about having files in version control when I've been actively changing them.
For this, RCS is good – it's ok that you don't give it total control over a directory, just a single file at a time.
Perhaps my mental-emotional workflow is just better suited to RCS in some cases. Emacs' RCS integration has been around for a long time, and is about ideal in my opinion. The RCS checkout, edit, checkin process is nearly frictionless in emacs for example. Another thing I like is, I have to explicitly check out a file to work in it, which tends to keep me from tinkering with a page unless I have a good reason to. (maybe I should allow myself to do that? but then, the workflow I have in emacs is pretty simple.)
I used to keep my websites in git, and it tended to be a bloodbath. I would regularly make a number of edits to the website at a time, and then sorting them out to be "units of change" was a tiny nightmare. You can't really do that with a collection of prose. (at least, I can't.) But with each bit of writing having its own versioning timeline parallel to but independent from the others, I don't worry about making coherent multi-file changes. The very nature of the version-control system I'm using encourages focusing on a single workpiece at a time. There are few times I want to make coherent changes across a whole website, but I can factor those out into a template and build system if I care that much.
I don't use RCS for everything, naturally. It's not always the right shape of tool. Projects where versioning a single file at a time makes sense, such as this website (which is mostly a collection of essays with some crosslinks), are normal. I also have a personal notes-and-agenda textfile, which is versioned in RCS. But when I'm writing software, it usually doesn't make sense to version a single file at a time – in that case, I'm building up a whole repository piecemeal, and a single unit of functionality can be spread across the whole directory tree. So for those sorts of projects I use git, or (rarely) fossil.
But RCS isn't all fun and games. The tooling sucks. It's hot garbage. RCS tools' output isn't easily parseable by a machine (and barely even makes sense to a human). Its branching model is weird, and not very modern. Merging doesn't exist in the file format in any meaningful way: commits have exactly one ancestor. Branches are needlessly limited to numeric branch labels. It's not like they couldn't be alphanumeric names; the tools seem to use bignums or strings to process branch names. But they aren't. I've done a little bit of work dabbling in modernizing the interface, if not the implementation. The impedance mismatch may yet be too much.