Nice intro article! I'd summarize it a little differently:

• To work with persistent data, use persistent classes. These provide the ability to store and access objects and/or rows. In other words, two different but related models, accessing the same data.
• To work with JSON, use dynamic objects {} and dynamic arrays []. If you need to store this data in addition to simply processing it, you can use a property of a persistent class, or you can use the DocumentDB feature of IRIS.
• When any data is stored in IRIS, it's stored in globals. These days, it's not that common to access data directly in globals. Using persistent classes to provide object access and SQL access is typically sufficient. But it is still possible, and can be useful. The "art and science" of good global design is another topic, as @Yaron Munz briefly mentions in his comment.

Ash is correct! I prefer to explain it slightly differently. I don't consider SQL injection as a "problem" with Dynamic SQL because you should simply never concatenate user input into a query (using IRIS or any other platform). Always use placeholders which eliminates the risk. And the other 2 SQL options (Embedded SQL and Class Queries) accept input via host variables like :minAge. All automatically sanitize the input.
One further clarification: years ago, it's true that Dynamic SQL was the only one of the 3 options that was compiled at runtime; the other two were compiled at class compile time. But since Runtime Plan Choice (v2021.2), queries with input parameters in the WHERE clause (as discussed in this post) are compiled at runtime, whether you use Dynamic, Embedded, or Class Queries.