The section you're referring to is the work underway to increase write performance, which is currently bounded by the master node's ability to process bplogs (an internal structure used to detect write-write conflicts).

re: 'the application level has to handle [sharding]', the table partitioning described in this section is merely a conceptual model 'assigning' masters to what are presumably non-overlapping row ranges in order to increase write throughput (writes/reads will be processed via that specific master). The behaviour of the system still resembles a single node database, this is alluded to intermittently throughout.

(also CRDB is the preferred acronym for CockroachDB haha, source: interning there)