0👍
I think the behaviour you describe makes sense.
In a regular worker, uwsgi loads a WSGI app that makes django load the settings, and as part of that configure the global Python logging system. Library code that is run by the django app and contains logging statement ends up being handled by the logging config (without having to know that django exists or configured the logging system).
In a mule, uwsgi only runs the code that you give it, not the wsgi module/script defined for regular workers, so nothing is configuring the logging system. The mules are still running within the same environment (uid, gid, chdir, virtualenv, pythonpath, env vars like DJANGO_SETTINGS_MODULE), so calling django.setup() (or django.configure_settings) will import your settings and configure the global logging system (global to the Python process that is the mule worker), fixing your logging calls.
Last piece of the puzzle: the django.conf.settings module is a special lazy object so that it can be imported by various modules before django has finished configuring itself, and defers really loading the settings until something tries to access a module attribute. This behaviour can be obtained more explicitly in modern Django versions with django.setup().