If you want to see how things can get tangled in a preamble have a look at the preamble of the Comprehensive LaTeX Symbol List. It might not be exactly spaghetti code but it can certainly be classified as code soup!
So you are right, you need to have a strategy and start working on it early in the development of your document. The tips below are from my own workflow and observations.
Early on, when I started with LaTeX, I realized that having used numerous macros and packages to change the looks of almost every single parameter originally set by the LaTeX book.cls, I would have been better off developping my own class and this is my first tip.
1. Consider developing your own class or package to hold your changes.
It is as simple as hitting a save as button to save the base class .dtx file and its .ins file. It will get you going with literate programming and honestly it should not take longer than an hour or two to find out how it all works. When you use doc for the first time you might get disoriented, but eventually you get used to the conventions. Another advantage of this approach is that at the beginning of developing a new document, you will find out that on Mondays, Wednesdays and Thursdays, you will want your document to look one way and on the rest of the days of the week you will want it in another way. By writing your rationale down using literate programming, it helps you settle your ideas.
2. Have the packages and own related commands, near each other
For smaller changes, i.e., write short packages, either using the doc/docstrip system or if you are in a hurry just use the package filecontents and write them on the fly while developing the document. This tends to remove a lot of code and comment lines in the preamble. I have all maths related macros normally in a package called moremaths.
% MATHEMATICS
\usepackage{amsfonts}
\usepackage{amsmath}[2000/07/18] %% Displayed equations
\let\equation\gather %% See tabu and hyperref docs
\let\endequation\endgather
\usepackage{amssymb}[2002/01/22] %% and additional symbols
\usepackage{amsfonts}
\usepackage{xfrac}
\usepackage{stmaryrd}
\usepackage{mathtools}
\usepackage{eucal}
Similarly, for tables
%% Tables
%% TABLES
\RequirePackage{array}
\RequirePackage{booktabs}
\RequirePackage{longtable}
\RequirePackage{tabularx}
\RequirePackage{dcolumn}
\RequirePackage{multirow}
%% Set some local commands and colors
\RequirePackage{colortbl} % for colored table cells
\definecolor{green}{rgb}{0.1,0.1,0.1}
\newcommand{\done}{\cellcolor[gray]{0.9}done} %{0.9}for done tables
%
%
3. Divide the preamble into headings, such as typography, graphics, maths, sectioning etc.
If you do not develop your own class and use any of the major classes such as Koma or memoir, you will discover that in general these classes have their own configuration commands for every possible change; it helps if you divide all the relevant commands in sections. If the sections grow, i.e, if you have too many typography save the code in a package and name it moretypography or moremaths etc. Again here, if the preamble grows question the need for your own class.
4. Have the problematic package settings in their own packages e.g., sethyperef or setlistings package etc.
Some packages are difficult to set and can give you problems if they are loaded before or after some packages (See Which packages should be loaded after hyperref instead of before?). Others need some complicated and long settings. Again here if you work on a long documents it may be worth changing these settings to small packages. If you identify sources of errors better save and restore commands rather than move them around. For example the verse package gave me problems with the macro theHpoemline and I normally only load it together with the following macros.
\let\oldH\theHpoemline
\let\theHpoemline\undefined
There are a lot of similar techniques in the Comprehensive LaTeX Symbol List, preamble, worth a read.
Certain commands are only allowed in a document preamble. For example, if you use \usepackage{<package>} within the document environment, LaTeX conveniently "suggests" the obvious:
LaTeX Error: Can be used only in preamble.
And, since both \input{<file>} and \include{<file>} do very similar things - including the contents of <file> in your document (the latter is a little more elaborate) - you can't include a full-fledged or stand-alone document with its own document class and preamble via \input or \include without some help. Nor will preambles be interlaced sequentially. The difference is explained in When should I use \input vs. \include?
Your only solution is to use a package or document class that can handle (circumvent) this restriction. Options include the subfiles package (not distributed with TeX Live), combine or the standalone package/class.
A good place to start is Make a .tex file that combines complete .tex documents in subdirectories. The main idea is that you have a master (or main) file that covers all the sub-file preambles and requirements, since the sub-file preambles will be lost at the time of inclusion.
Best Answer
Short answer: no.
There are two reasons for this: a 'LaTeX' one and a 'TeX' one. The 'LaTeX' reason is that the mechanisms for loading packages are deliberately disabled at the start of the document, so for example
\usepackagegives an error. The decision to do this is done is partly based on a desire for 'logical structure' but mainly due to the underlying 'TeX reason'. TeX reads files sequentially and processes as it goes. As such, there is no 'first see what packages are loaded' phase to running (La)TeX: package features can only be used after they have been loaded. As LaTeX can't know what any particular package does, this means they all need to come in the preamble before 'stuff' is typeset: the outcomes might otherwise be altered.Note that you can
\inputa file anywhere, so you can for example define commands in a secondary file then load it part-way through a document. That's not encouraged: experience suggests that commands should be defined for all of a document, not just part of it.