You're confused by the word transactional. The parent meant transactional in the sense that it's oriented for transactional systems (OLTP). Redshift and other columnar DBMSs are designed for analytic workloads, rather than transactional. Nevertheless, they are relational and support database transactions.
People in the database space use the term "transactional database" loosely to refer to databases optimized for handling simultaneous inserts, deletes and updates at rates often measured in thousands per second - the kind that you would use to say power an airline ticketing system or inventory management for a retailer.
Just because a database can support transactions does not mean that it is geared for transactional workloads, and hence would likely not be called transactions.
OLTP+OLAP is called HTAP. Its an active area of research but to my knowledge there is still no silver bullet there - systems that do it often store data in both row and columnar format to ensure they are optimized for both, with associated overhead.
I guess I have always thought of a transaction as an ACID-compliant concept and "transactional database" to refer to a DB that supports transactions[1].
To that end, I always thought of OLTP vs. OLAP model and engine optimizations to be more or less orthogonal to whether or not a DB is transactional. I would even suggest that the inclusion of transactions in Redshift as justification for my seemingly unconventional view:
> Some PostgreSQL features that are suited to smaller-scale OLTP processing, such as secondary indexes and efficient single-row data manipulation operations, have been omitted to improve performance.[2]
But who knows, maybe I am barking up the wrong tree so-to-speak.
...
> The precise goal of databases like Redshift, ...
Huh? It was my understanding that Redshift was a fork of PostgreSQL and is therefore not only transactional but also relational.
Simple Google search confirms transactions in Redshift: http://docs.aws.amazon.com/redshift/latest/dg/r_BEGIN.html