Maybe then the last level cache line should be the size of the DRAM page (2 Kbytes or multiple of), so that the DRAM chip does not have to do the read-[modify]-write itself of the 2 Kbytes (DRAM cell reading is destructive) - but that changes the DRAM interface, and may increase the used bandwidth. The DRAM content would then be invalid (read once, not refreshed) inside the DRAM chip as long as the data is in the cache, and the cacheline has to be written on eviction even if not modified (does that happens often? Could we encode "memory content useless, no need to update"?). And that would reduce the number of DRAM page updates each times a cacheline is evicted, probably most noticeable on high count core processors (currently no opportunistic update of DRAM page with multiple cachelines while that DRAM page is selected).

For this to work in a system where higher-level caches operate on smaller granules, your last-level one should be inclusive. Indeed, as higher-levels record a subset of this 2KiB granule, if the last-level isn't inclusive, there can be partially-valid and partially-dirty lines. Thus, you still need to RMW DRAM. One way to solve this is to enforce the entire granule to be recorded in higher-levels, through cache stashing (send the rest of the cache-line to the requester through the snoop interface). On a last-level eviction, you probe the directory/snoop-filter, and retrieve the entire granule. This is equivalent–but not identical–to supporting 2KiB granule in higher-levels, though with greater complexity.
If you opt for inclusive last-level cache, there is a serious performance threat. The farther the caches from the cores, the more difficult it becomes to build an efficient replacement policy. While close-to-core caches have deep knowledge of hot lines, a distant L3 has very little. Cores can send activity information to the inclusive L3, but interconnection network's bandwidth will inevitably limit the rate of information even with dedicated channels, and it will consume a lot of power. The last-level has then to update itself with that information while providing fairness in heterogeneous systems. One way to reduce this thread is to build an L3 an order of magnitude bigger that higher-level caches, with high associativity. To minimize high associativity cost, you could implement a skewed- or Cuckoo-cache. However, you'd like to avoid swapping lines in your Cuckoo cache but just the tags, to limit power consumption. Impossible, as multi-parity error could happen in the SRAM-based tag-RAM.
In conclusion, don't do multi-granule cache-lines, at least outside of a core. You could eventually do it in between L1 and private L2, with all the difficulties described above.

Hugo