From what I gather from this answer, if write quorum is not achieved, cassandra does not rollback the writes from the database that persisted the write.
What is the point of having a write quorum at all? How is it different from a best-effort write or sending writes to all the nodes and only waiting for one success?
There is a foundation error in your understanding. A crucial point about data replication in Cassandra is that writes are sent to ALL replicas in the cluster.
For example, a keyspace which has 3 replicas in 2 DCs, the mutation(s) in a write request are sent to ALL 6 replicas (3 replicas x 2 DCs). For the write request with consistency QUORUM to be considered successful, at least 4 (of the 6) replicas must acknowledge the write within the write request timeout.
IF not enough replicas acknowledge the write, the coordinator will reply with an UNAVAILABLE error to the client/driver. Now here is the missing piece -- the driver you're using has to make a decision on what to do next depending on how you've configured it.
For the purposes of this discussion, I'm going to use the Cassandra Java driver since it is the most popular. When a query fails, the Java driver will sometimes retry the query based on the configured retry policy. The default behaviour (DefaultRetryPolicy) for an UNAVAILABLE write error (not enough replicas acknowledged the write) is to retry the query on the next node in the query plan. If the retry fails, then you as the developer have to decide how your application will handle the failure, e.g. issue a corresponding DELETE if rollback is required by the business rules in your app.
Bottom line is that the consistency level is important since it determines whether the write request is successful or not. Without it, your app has no visibility on the state of the request and it would be impossible to determine what to do next.
If you'd like to know more about how the Cassandra Java driver handles failures, see the Retries page in the docs. Cheers!