I've never understood the appeal of AMD loaders for the client-side web in general, although they did make some sense for mobile at one point because resource files didn't cache on Android and parsing performance wasn't great.
If you attach script files in 3 categories in the following order,
- General 3rd party libraries
- App-specific in-house libraries that reference the 3rd party libraries
- Implementation code that can reference both
... where's the problem? Scripts that aren't used on a page aren't ever more than a one-time loading performance hit because they're cached. If juggling dependencies within those categories just by appending script tags in the right order has become an exceedingly difficult task, I'd call that an architecture/file-management issue that shouldn't be hard to handle with a little clean-up/consolidation.
If two functions or constructors share a dependency, it usually makes sense to have everybody in the same file and that shouldn't be hard when you've separated the code that implements, from things that are used by implementation, from 3rd party things that can be used anywhere. Within a given category don't split things into separate files if they share a common problem domain. And of course combine/minify in production.
If all you're using JS for is client-side templating, I would not expect anyone would want to use AMD. As a general rule, don't use anything that doesn't provide an obvious/immediate benefit. It's easier to add later than it is to take away.
You could see AMD loaders as the missing
include of JS. Do you need a big site to start including some files in others?