Solution
Reordering the load order will solve this issue: Gonzalo's answer demonstrates this nicely.
Underlying cause
The underlying problem here is how the file easy.sty does its allocation of registers:
%
% define dimens for internal computation.
%
\@tempcnta=30\relax
\@whilenum\@tempcnta>\z@\do{%
\expandafter\global\expandafter\newdimen\csname @easy@hsize\romannumeral\@tempcnta\endcsname%
\expandafter\global\expandafter\newdimen\csname @easy@vsize\romannumeral\@tempcnta\endcsname%
\advance\@tempcnta by\m@ne
}
This looks dense to the non-expert, but the key thing is that the \newdimen is being prefixed by \global. This is not necessary (dimensions are allocated globally by LaTeX), but is normally harmless.
The error arises if \global\newdimen occurs at the 'wrong' time. Classical TeX had only 256 dimens available, while e-TeX made many more (64k) accessible. However, the LaTeX \newdimen command is set up to only use the 256 classical ones, and so to actually use the 'extended pool' you have to alter part of the kernel. This is what the etex package does. However, it is set up to first use the 256 'standard pool' registers before altering how allocation is done for the 'extended pool'. That is all fine and usually is transparent. It goes wrong, however, if the switch happens when \newdimen is prefixed by \global, as the \global ends up 'in front' of an internal \begingroup, and that gives an error. (The error doesn't actually break the document, but no-one wants an error on every compile.)
Reordering loading will almost certainly skip the issue as it moves when the switch happens, hopefully away from the \global\newdimen use. A 'better' solution would be to alter easy.sty to not use \global, but as this file is 12 years old at time of writing I would not hold my breath on that. Perhaps the best solution would be to change etex to allow for an deal with the use of \global here: tricky and again a change in a file that has been unchanged for a long time.