Why activerecord usually supports both reading and writing?

In a few programming languages there is an "active record" concept. The same class supports both reading and writing (CRUD).

I am now implementing my own active record.

While implementing it I thought:

When reading, we read all fields which application code requests (out of the set of all columns of a table).

When writing, we usually store a fixed subset (all fields which were set by setters) of all fields.

Note that the set of read fields is usually does not match the set of fields we are to write.

It is (at least in our company) probably unusual that we read the entire record, modify it and store.

Instead it happens in such way as this: We create a Web form with reading a record, the form is POSTed and then we store it into the DB with writing a record.

This way code splits into two unrelated halves: The first part only reads and the second part only writes. As such, why we need an object which can be both read and written?

I suggest that there can be done two independent classes: One for read only and the second for writing (create of update) only. Deleting by can be done with yet another class.

My question: Why typical active record implementations were designed to support both reading and writing? (Well, I anticipate the flow when some fields are read and then modified and store into the DB; but even in this flow it can be done (with a slight increase of the length of the program) with two independent classes: The first one used for reading and the second one for writing.)

What are design decisions backing typical active records? Are uses when it is useful to have both reading and writing in one class frequent? Can you give examples?