I think the wikip page provides a reasonable explanation:
database vendors scrambled in the early 1980s to repackage existing products with a relational veneer.
And Rule 12 expands Rule 0 to exclude single-record-at-a-time updates that would make the database content (temporarily) violate integrity constraints.
"existing products" include indexed-sequential access and hierarchical models -- for which the programmer needs to know how each file is structured, and follow those 'Access Paths' rather than issuing a
SELECT ... FROM ... JOIN ... WHERE ... request, where the DBMS figures out the route to access and returns multiple-records-at-a-time.
Does it mean that you could manage the database by only using a language like SQL?
Hmm. Codd had something of a love-hate relationship with SQL. The access language(s)/algebra in his seminal 1970 paper were not SQL. SQL was invented by IBM engineers who (IMO) didn't understand what Codd was proposing. The early forms of SQL they produced were aimed at being easy for engineers to implement, not at being elegant or expressive.
In early 1970's as the industry became aware of Codd's ideas, several other manufacturers produced implementations, with a variety of access languages, some of which were closer to Codd's 1970 formalisms. But IBM (Oracle)/SQL won the race. So we're stuck with it.
So, no Rule 0 doesn't mean through SQL specifically. It does aim to exclude mechanisms that insist on accessing rows/records in a specific sequence, and especially the idea of a query returning records of mixed format that need program logic to distinguish by a 'record type' field.