Your changed _configure() will also break Canvas/Listbox.itemconfigure(), Menu.entryconfigure() and a number of other methods, Tix is also affected. It will also break third party extensions that use _configure(), like pybwidget.
As another python motto says "Special cases aren't special enough to break the rules." :) I believe that breaking existing code is not justified by the "special case" of the tk_busy_configure() syntax, resp. the desire to avoid 10 extra lines of code.

The change to _configure() I suggested otoh leaves all the existing configure()-like methods intact, and it seems at least very unlikely that some third party module uses a configure()-like method that adds the window path name to the cmd-tuple (which indeed would break my _configure() example.

However, following the "explicit is better than implicit" motto, I believe the best idea, if _configure() should be changed at all, is to add a new option to let the programmer decide if the window path should be added to the cmd tuple, which defaults to a value that keeps the old behavior intact, as in this example:

    def _configure(self, cmd, cnf, kw, usewinpath=True):
        """Internal function."""
        if kw:
            cnf = _cnfmerge((cnf, kw))
        elif cnf:
            cnf = _cnfmerge(cnf)
        if usewinpath:
            cmd = _flatten((self._w, cmd))
        else:
            cmd = _flatten(cmd)
        if cnf is None:
            return self._getconfigure(cmd)
        if isinstance(cnf, str):
            return self._getconfigure1(cmd + ('-'+cnf,))
        self.tk.call(cmd + self._options(cnf))

Then busy_configure might look like:

    def busy_configure(self, cnf=None, **kw):
        return self._configure(('tk', 'busy', 'configure', self._w),
                                cnf, kw, usewinpath=False)