As a plain datapoint, I can say that I won't update GRDB public apis, sample code in documentation snippets and guides, as well as demo apps, with any. Not until it becomes necessary (warnings or errors).
Those any, in function signatures, documentation, and sample code, are much to much "in the face" of the user, who may not even be aware of this new Swift 5.6 feature.
In the particular case of documentation, where you really not want the user to be distracted as you try to transfer pieces of knowledge, introducing any would be a big mistake (when I wear my hat of documentation writer).
Finally, having chosen (any P)? instead of any P? is, IMHO, a design mistake. The need for an optional existential is not less frequent than the need for an optional of another type, and those extra parenthesis are a chore to write, and a chore to read. I hope this decision is revisited: the plain any P? currently won't compile, so this form looks like it could find a purpose, even if it is less logical.
For example:
func f(_ dict: [String: (any MyProtocol)?]) { ... }
is more difficult to parse and understand, dare I say uglier, when compared to the two alternative forms:
func f(_ dict: [String: any MyProtocol?]) { ... }
func f(_ dict: [String: MyProtocol?]) { ... }
GRDB has plenty of such heterogeneous but convenient dictionaries, when it allows the user to match database columns (String) to database values (Int, String, Date, etc):
// A database row for testing purpose
let row: Row = ["id": 1, "name": "Arthur", "score": nil]
// A request on a unique index:
let player = try Player.fetchOne(db, key: ["email": "..."])
// etc.
