Unfortunately a multitude of the articles on this subject tend to generalize away the specific key facts that actually matter when making a decision on this matter, which has led to a lot of misinformation and confusion.
First and foremost, there is nothing that makes a NoSQL database system faster when it comes to reading and writing data, no matter how much data one is considering storing. Both are equally capable of reading and writing data at (roughly) the same speeds, on the same hardware, all things equal. A terabyte of data is a terabyte of data, whether it's stored using a NoSQL database system or a RDBMS. This is one of the biggest points of confusion people stumble on when considering when to use a NoSQL system. It doesn't sound like you're specifically confused by this, but I just want to make it clear to future readers.
That being said, the three points you mentioned are pretty much the primary things to consider, so let's briefly break each one down:
1. Dealing with large amounts of data and scalability is a concern: NoSQL was initially incepted to solve the the problem of infrastructure scalability by allowing more flexibility with horizontal scaling across multiple servers back when companies were starting to reach the vertical limitations of the hardware in their servers. NoSQL achieved this by trading off some of the ACID principles a traditional relational database management system (RDBMS) would have to adhere to, such as immediate consistency for eventual consistency, which improved it's flexibility for scaling.
In modern computing, hardware and infrastructure as a whole (e.g. with cloud services as an option), and even RDBMS themselves have evolved enough such that the original scalability problem that NoSQL was invented for has now become a moot point, mostly. That's not to say NoSQL has no use cases, for example mobile development tends to be a fitting place one might find the natural horizontal scalability of NoSQL a fitting choice for their applications (because of the eventual consistency needed when distributing the data across multiple devices that need to support an offline first design). But scaling vertically, whether physically, virtually, or in the cloud, is now just as easy as horizontal scaling is, and RDBMS can even easily scale horizontally nowadays as well.
The only reason this point might matter to a developer today, is if your infrastructure team truly can't maintain the vertical scaling of a RDBMS and for some unique and interesting reason finds it much easier and quicker to scale the infrastructure horizontally.
2. Schema changes are regular with each iteration: While a NoSQL database lessens the concern for schema changes at the database layer, it doesn't remove the fact that the schema does still need to be maintained by the consumer which will be built on top of the data. So while there may be a little more work upfront maintaining schema changes in a RDBMS, it is not something foreign or should prohibit one's choice from using such a system, as typically no matter how one chooses to store their data, the idea of a schema to that data will always exist at some point of its lifecycle. And making schema changes in a RDBMS generally isn't that hard to maintain (unless you're again trying to synchronize those changes across a distributed set of clients such as mobile devices with offline first in mind, then a little extra thought is needed).
3. The data you are dealing with is non-relational: This is one of the most defining characteristics in my opinion when making the decision between different types of database systems. If your data has a strongly defined relational schema to it, then it usually makes sense to store it in a RDBMS. Doing otherwise can dumb down the architecture of your data's design and make it more difficult to query for more complicated use cases later on. If the data isn't relational, then a NoSQL system might prove to be a simpler home for your data, if you never intend to query it in more complex ways.
Based on the information you've provided, unless your infrastructure team has a significant bottleneck with scaling the hardware of your servers vertically, I'd recommend using a RDBMS since your data is strongly relational already.
For more information, please see this DBA.StackExchange answer I've written on the subject in the past that talks a little bit about the differences of the two types of database systems and touches on the history of NoSQL.