I would say that the command interface isn't supposed support queries, and the write model should not necessarily be exposed to client applications for that purpose.
However, the notion you're looking for in the first question:
is it conceptually wrong to query write model in order to get the most recent state of an entity for the page?
seems to be "read your own writes", which can be very important to some applications. I suppose one could provide a buffer that remembers one's own session writes. However, what I do is a bit different.
I return a timestamp (or some other value that supports >= comparison) from the command interface, as well as the query interface. The timestamps are forwarded from the write model to the read model along with other (changed) content.
Then when necessary to read my own writes, my client queries asking for data of interest as of >= the timestamp returned by the last command it issued. This way I know the query is reporting content as of the client's latest change.
I don't understand the follow up question:
If I choose to query the Read Model (typical implementation according to CQRS Journey Book) how can I deal with optimistic concurrency?
As @Alexus says, the read model is read only so doesn't have to worry about multiple writers. However it is not totally read-only as it must be repeatedly updated somehow from the write model. The optimistic concurrency should be handled internally by the normalized write model SQL store and also by the denormalized read model SQL store. (If you're using a non-SQL store for the denormalized read model, you should be aware that there is a difference between responding to read model queries with stale values on the way to eventual consistency and responding with inconsistently mixed values on the way to eventual consistency.)
Sorry for the confusion on my part. The term optimistic concurrency is overloaded... This term normally (in my mind) refers to a kind of transaction overlap capability found in the internals of the database. However, CQRS uses this term to refer to a similar capability between client application and command server (and query server). You provide the timestamp (as I described above) also with commands, in a form that asks the command to fail/abort if the timestamp is old. Note that it is recommended that each aggregate have its own timestamp for fine granularity, so we're talking about using the logic I described above for each aggregate.
So this creates a full cycle or loop regarding the timestamps/version numbers. When your client application does its first query, it omits the timestamp, though it receives timestamps back; when it does a command that is (most likely) based on the query information it has at present, it passes in the query timestamps with a flag to abort on timestamp old. When the command completes, it provides a timestamp that the next query can use to see if the last command's results are in the read model yet (or to wait until so). The query returns new timestamps, and the next command is based on those latest timestamps (with abort if old set), and so on. (Sometimes, if the UI knows it hasn't refreshed in a while it may premptively do so.)
I think you could start with a single global timestamp/version number for the whole system; get that working, and later make the timestamp more granular (e.g. per aggregate instance) for better concurrency. As @JDT is answering, this is complicated stuff already, and more so if you take it all the way to replicas of command processors for the same aggregate.