Doesn't sound dumb at all. I tried it many times - and I refuse to call myself dumb - at least not entirely!
All includes are the first thing loaded and run as part of the DBA script. Trying to load a library using #include after the app has launched just won't work. Look at it like this, once the app is started, it boxes all the script it has available to it in a specifically sized container. The interpreter knows the size and the location of the container and that's where it's gonna read the code from. An #INCLUDE command actually combines the library code with the main program as soon as the main program is run, and then the container is shut.
The idea of using an engine of some sort is the only way to include dynamic data into the app. When you are moving a character around, you are not changing or adding to the program, but you are sending input through open channels designed to read that type of input and the app is programmed to interpret those.
If you really wanted to and didn't mind spending the time, you could create a custom file that had DBC commands in it. In your engine, you would have to parse the commands out (i.e. separate them into usable chunks or commands that you preprogram) and send them to routines or functions that will perform an operation based on these commands. If you sent a command like MAKE OBJECT SPHERE, you would have to have your own function that understands those words and then execute the appropriate DBC command. So basically, your engine would have to become an interpreter of it's own. You could make an engine that reads and runs a file of native DBC commands, but you'd have to program each command yourself.
In creating a game maker, you don't want to reprogram every DBC command. That just doesn't make sense. You want to create an engine that runs a certain way, maybe makes certain types of games, and you want to be able to feed it a data file that will invoke the engine into performing within a set of parameters.
Enjoy your day.