In many programming language implementations, the compiler will turn on certain optimizations if it knows that a variable will not change after its initial assignment. Wouldn't this stretch to persistent data too? If the database knows that a certain column will not be updated after a record is created, couldn't it change the way the data is stored, or cached, to improve performance?
Sure, some database platforms do handle read-only or mostly-read data differently.
For example, in Oracle, you can choose to enable results caching, which lets the database engine save query results and reuse them when it sees the same query come in again. That's really useful for data that rarely changes. However, you wouldn't want to bother enabling that in scenarios where you know the data will change.
Another example: in SQL Server, if you set the entire database as read-only, SQL Server handles locking differently. It doesn't need to worry about transactions when you can't modify the data.
I know what you're thinking: "Why can't the database engine figure it out?" Because data access patterns can be complicated. For example, you might have a data warehouse that is loaded from scratch every night, and then is read-only all day long. You wouldn't want the engine to bother even trying to cache ETL query results overnight during the loads, so you'd want to turn that kind of thing off overnight to maximize load speeds.