I'll give a bit of rationale for JacquesB's comment with which I completely agree.
First, for most domains RDBMSs can very likely scale to the load, and by the time this stops being true (if it ever does), you'll have a lot more understanding of your data and the queries you need to support (and presumably a lot more money). In other words, an RDBMS suffices for most use-cases for, at least, quite a while.
However, the real reason to use RDBMSs is flexibility. Using a typical key-value or document store means encoding a preferred way of accessing the data. For your example, this might mean that replies are child elements in a "post" document. This is great when you want data in just that format. It becomes far less great when you want, say, to get all the replies by a specific user. Now you have to walk over every post in the system and check all replies. In a relational database, this query would be trivial and, perhaps with the addition of a few indexes, would likely perform reasonably well. To get reasonable performance from the document store would require rearchitecting the data model, or, more realistically, storing a copy of the data organized by user. The latter is essentially manually creating an index. Sarah Mei's article outlines exactly how this plays out in detail.
Adding to the flexibility of RDBMSs, most are very featureful. Want to store JSON? Fine. XML? No problem. Need some full-text searches? Well, you should probably use a dedicated solution, but you can at least start meeting the need without changing technologies. Need integration with message queues, ORMs, Excel? No problem. Need more consistency? Use SERIALIZABLE transactions. Don't need that much consistency? Drop to READ COMMITTED, which is often the default! This monolithic, kitchen sink approach is one of the downsides of RDBMSs, but it definitely improves agility when you can use an out-of-the-box, integrated solution to, at least, prototype rather than needing to evaluate and integrate multiple 3rd-party solutions.
One of the things traditional RDBMSs do poorly that NoSQL solution usually do well is distribute. Virtually all of them can be used in a distributed way, but they are much more complicated to set up and maintain than most NoSQL solutions. So-called "NewSQL" systems, such as VoltDB, do give an experience much more like NoSQL solutions with regards to setting up distributed clusters. Of course, if you are using a database-as-a-service from a cloud provider, then you don't have to worry about this.
The place where I think most key-value/document stores fit is as a caching layer/secondary index. So, I actually do think you should "manually create indexes" using a NoSQL data store. I just think they should be "indexes" of data stored in a different system, typically an RDBMS. Another, closely related, way to think about this is the NoSQL data store is a materialized view of data stored elsewhere. This suggests a bit more generality: the "materialized view" may be sourced from multiple primary sources each the source of truth for their respective data, and they don't need to be RDBMSs, e.g. some might come from an LDAP server. RDBMSs do, generally, do very well as systems of record. Most NoSQL solutions usually should not be used as systems of record. This splitting of the work alleviates pressure on the system of record, while not asking NoSQL solutions to do things they aren't designed to do. Most of the problems with NoSQL solutions (weak consistency, redundancy, preferred access paths, limited or no integrity checking) don't matter when they are used this way.
Revisiting the earlier scenario: You're a year in to the project and you have 100,000 users. Your sole RDBMS database combined with standard web page caching is performing adequately until a viral article leads to a huge spike in traffic. Your RDBMS struggles to meet the demand. To avoid this in the future, you consider using a NoSQL solution to store AJAX responses in a ready-to-go manner for posts and replies. You realize this may mean that users see different looking reply threads at different times, but you accept this. By using sticky sessions, you can at least avoid the situation that a user fails to see their own reply after posting it. At this time you get the requirement to add a "Replies by User" feature. In a day, you write the simple SQL query and, after a bit of initial performance testing, add a few indexes. You don't expect this to be the subject of a spike in demand, so you just go directly against the RDBMS. Since you're using a snapshot-based isolation mode, this neither blocks nor is blocked by any other (read or write) request.
To directly answer your question, I'm pretty confident most comment systems are based on RDBMSs. It is very unlikely your use-case is an outlier where an RDBMS would not suffice. Usually the structure of the data is not a significant factor for choosing a database solution (full-text and graph-based data may be an exception). Usually what's more relevant is how the data will be used: issues such as latency requirements, consistency requirements, availability requirements, the cost of losing data, how independent the data is, and generally how you want to query the data. For most OLTP loads, including comment threads, RDBMSs make reasonable trade-offs for these issues.
