There's another dimension to this: software engineering can incorporate some things which are things harder to learn on the job. i.e. suppose you're a on-the-job learned Perl programmer, maybe you started as a first line tech, then moved to sysadmin, learned Perl, and eventually moved into Perl full time. You might never come across in your professional life a programming language from a paradigm outside your language. There's no reason in that career path why you might come across a language from the functional paradigm (like Haskell or OCaml), or the logical paradigm (like Prolog), or specialist programming language (like R or Matlab). You also might not come across a a number of data structures or programming concepts which a good university degree should expose you to. It's not that you would necessarily use any of these specific ideas day-to-day in your work, but it gives you a different way of thinking about the problem which helps you come up with different solutions than you otherwise would.
In comparison, something like being a network engineer or a systems engineer is more of an engineering discipline centred around application and is much less theoretical (by the nature of the job). This might be changing slowly with things like SDNs, but on the whole, configuring routing on estate of Cisco switches is a very different type of task to say, writing a compression algorithm, and one much more aligned with on the job training.
(and ignore the exaggerations)
