Ok, for COBOL and assembly languages, you are quite right - for COBOL it has to be that way, and mixing variables into the code for assembly is simply ugly. I don't know anything about Applesoft Basic, so I'll give you the benefit of the doubt there too
However, you should take that advice and attempt to generalise it to multi-file and modular systems such as DBPro allows you (although DBPro isn't truly modular).
Modularisation is used to keep related functionality in one place (such as input routines for example) - it's also used for data hiding (but this is the bit DBPro can't do). This includes not only functions and subroutines, but also the variables that they operate upon. Doing so allows you to reuse the module in another project simply by taking that 1 file across to the new project.
If you keep your variables in different files from the code that operates on them, then to do this you have to hunt for its variables, identify all of them properly, and then copy/paste them into the top of your new main file, hoping you haven't missed any.
IMO, putting it all in one file makes it all simpler - not that it'll work for everyone though, as the majority of people I see who 'appear' to modularise in DBPro, tend to access the variables and arrays directly instead of via functions - that's why they also have problems with types too (and declare these at the top of their main code) as the definitions are very sensitive in their placement in the code - you can have problems accessing a typed variable if the variable is accessed before the type definition appears.
The sequence I use for a module is like so:
1. Type definitions.
2. Variable and array definitions.
3. Initialisation function (or subroutine).
4. Other functions (or subroutines) for the module.
All access to anything within the module is via a function, even reading a value from a simple integer - you may want to change that integer later to something else (eg an array if you need to hold multiple values), but if you access the variable directly, you have to change code throughout your system, not just the module.
I treat the main file also as just another module, although technically, using my definition, it doesn't need to be.
Ok, that's enough preaching for now