> Tools like str(x) and int(x) are frequently used as if there were functions.

The description of each object already mentions the function/type duality, and links to https://docs.python.org/3/library/stdtypes.html.
If they are grouped together, a paragraph like "the objects in this section can be used both as constructors or as functions" can be added at the beginning of the section

Similarly a paragraph pointing to itertools can be used in the section that describes map/zip/filter/all/any/etc.


> For the most part, I don't think the distinction is meaningful or helpful.

There are two distinctions I want to make:
1) grouping the built-in types;
2) grouping related functions;

1 should be especially useful to people that are new to the language. Here they can know quickly what are the Python equivalents of the  objects they use in other languages (e.g. a structure similar to a C char*, or a JS object, or a PHP array...) and discover objects that might not exist in their language (e.g. sets, bytes, memoryviews).  
2 is useful to find related functions.  For example, if I'm looking at map(), I might be interested at zip() and filter() too, or if I'm looking at getattr(), having hasattr(), setattr() and delattr() nearby will make it easy to discover them and consult their docs.

> As a reference point, authors of Python books have avoided making a
> distinction and have favored the alphabetical ordering we have now
> (which has the virtue of making functions easy to find).

The table at the beginning and ctrl+f makes the alphabetic order almost useless, so more meaningful orderings can be used instead.