Yes, good point and I can see how a folder full of individual files, representing "Release 14-Feb-2017" would work the same as one-big-file, and pros and cons of each.
We post-process the SQL a fair bit:
We move "sections of code" to enforce execution sequence. For example we might move a "CREATE PROCEDURE" shell statement to the top to ensure that it existed when a subsequent, different, SProc made an EXEC to it. It would be possible (in pretty much all cases) to change the execution order of the individual files to achieve the same, but if I were to move the whole "file" then something else might fail, whereas just moving the SHELL Create solves that.
We also remove comments and spaces, and we have markers in the code that require changing on rollout - such as comments indicating where DEBUG code is to be removed for Production. I could do that on all individual files too, but being lazy ! I've just written a Find and Replace macro for my editor, rather than a function that is capable of acting on multiple files.
All that said : I have been toying with having a Multiple SQL File Executor program which could do something intelligent with any errors that are raised. Currently it can be a pain to sort out an error; we do have PRINT statements top & bottom of each file, so they tell me which SProc / Trigger / View etc. was executing at the time of the error, but by then the rest of the script has continued to run - sometimes causing havoc. My thinking was that if I have a list of individual files called USP_MySProc, UTR_MyTrigger and UV_MyView (or whatever naming convention is appropriate) my executor could make an initial pass of the file-list and create SHELL versions of any object that did not already exist, so that none of the real code found anything missing. I would then just need to make sure that any SHELL routine had been replaced by something real.
Maybe I could generate the file-list file based on Dependencies in SQL?
One of the problems with executing a DDL script generated by SSMS is if something goes wrong a hailstorm of side effects ensues, which most probably results in restore from backup. Redgate's script generator gets around this by using (from memory, may be different, but principle the same) a #TEMP table to store whether there has been an error and preventing subsequent code from running. An executor could bail out at the first error more easily, as well as logging how many rows were updated at each stage (and comparing that against a known-good installation) and so on.