Django is a very nice framework for web applications. To be frank, several
aspects in our architecture proposal were influenced by some elegant
design choices in Django. However, there are several reasons for not using
Django as part of ACF. As you mentioned, one of them is the large
footprint. The basic Python and Django packages have a combined footprint
of 40 megabytes on my Fedora machine, but this is not the only downside.

You wrote that Django makes database access completely transparent. This
is true to the extent that you don't need to deal with SQL statements, but
the fact is that Django is tied to SQL databases only. If you look at
Django's model API, it is quite evident that you really cannot enhance it
to support non-relational backends.

There are some relatively small SQL databases, such as SQLite (used by
FreeNAS, 716 kilobytes on my machine), but this is not the main issue with
SQL. Most Linux applications read their configuration from files in /etc,
not from an SQL database, which means that you need to generate the files
from the database contents. I am not impressed at all about the way chosen
by FreeNAS developers. They have included the generation code into the
init script of each service (in /etc/rc.d). Embedding SQL queries and
configuration file blocks to shell scripts is not nice in my opinion.

Were I to design a Django-based configuration system, I would probably use
Django's template system to generate the files. (The template language is
not constrained to HTML, even though that's the typical use case.)
Nevertheless, we can do better with the proposed design for ACF. The
design is not limited to SQL but can also use e.g. Augeas as a storage
backend. Augeas implements a bidirectional translation between a
configuration file and a tree-structured data model, allowing the user to
directly edit the native configuration files of services. Without a
bidirectional translation, your manual changes would be overwritten by the
configuration system. This would be very annoying e.g. when for some
reason the system does not support the option you need.

Comparing with the architecure we proposed, Django is also inferior with
respect to handling concurrent changes. If enabled, Django's transaction
middleware ensures that all database requests related to a single HTTP
request fall into a single database transaction. This is not sufficient to
prevent loss of changes when two users edit the same data. There is an
add-on package called django-locking, but it is not really transparent to
module developers if multiple model instances are involved in the
transaction. In contrast, we propose a protection mechanism which is
completely transparent to module developers.

Some ACF use cases require streaming status information back to the client
as the operation progresses. Django does not support this very well, at
least in any production release. (Version 1.5 will have
StreamingHttpResponse class.)

Finally, remember that Django is a framework intended for implementing
relational database-oriented web applications with server-side HTML
templating. While it would be possible to implement CLI and SNMP
interfaces for Django models, the framework does not really help in that
effort. We also want to include dynamic state information e.g. from /proc,
but Django does not help there at all. I think it is better to design the
framework to take these use cases into account at model API level. As I
said, Django is a nice framework for the purposes it was designed to and
obviously has been developed by smart programmers. We will indeed let its
design influence ours. Even if we decide to implement the web interface as
a single page application (in JavaScript), we can apply some principles
found e.g. in Django's form API. We should also take a look at Dojo
Toolkit.