模块化的目的是什么？一是让依赖关系更清晰，二是让模块更容易复用，三是让模块更容易维护，四是提供代码预处理。
在ES3/ES5时代，JS只是作为控制页面交互的辅助工具，在这个时代，人们对JS开发的印象就是在JS里写写代码，然后用script标签引入HTML。如果看到网上有好用的插件，好啊，又是一个个script标签。
日久天长，你的页面塞了一大片script标签，维护起来各种麻烦。你知道某个插件已经不用了，可是不知道改移除的是哪个标签，因为它们之间的依赖没有清晰的路线图，简直是牵一发而动全身。而且没有任何模块化规范，为了模块之间的通信，还制造各种魔幻般的全局变量。
为了解决这些问题，业界提出了各种模块化方案。AMD、CommonJS、UMD还有ES6 Module就是其中的方案。
题主所说的RequireJS，是对AMD的一种实现。但是，现在用webpack的人更多，如果借助babel，直接上ES6 module更好，毕竟后者是ECMA钦定的标准。直接可以享受ES6+语法开发。
至于开发的调试？以前怎么来，模块化之后就怎么来。我没觉得有什么区别。
再说题主所说的移动端，不知你有没有做过代码优化、合并、压缩工作，这其实也可以作为模块化工作的一部分，有了这些流程，反而更利于移动端优化吧。
最后再说，技术就是在热炒中进步的，试想当年不“热炒”AJAX、HTML5，现在的web开发将是怎样可怕的地步。有些东西没人提及，不是因为没人用，恰好相反，那是因为，它已经无处不在了。
当然，你也完全可以固守在ES3时代，用jQuery操作dom，用全局变量通信，用目测来管理依赖，顺序加载，不压缩，不合并。但是，需要注意一点，不要把项目做的太大，不要把页面做得太复杂，不要引用太多插件，不然，维护起来就像洪水猛兽，前人挖坑，后人遭殃。

显然，LZ的纠结点在于，这么多人都在提倡模块化，而我目前没有模块化也没出什么乱子，于是产生疑问，模块化有什么用？

要搞清楚这个问题，我个人感觉其他人给不了你太多帮助，还是得靠你自己。不过还是简短说下吧，首先，使用一个工具，应该是在我需要他的时候，或者说使用了这个工具，我能做得更好，做得更快。而不是别人都在用，我不用显得我很low，所以我要去学。后者往往会导致一个严重的问题，就是用着用着我发现我不知道为啥我要用，我感受不到好处，更不清楚什么情况下需要用，什么情况下不需要用。要解决这个问题，其实也不难，过个1，2年做的东西多了，做的东西大了自然就明白了，也就能合理的选择和使用工具了。

其实在于使用场景。如果你一个简单页面，我想说用这么多复杂的框架干嘛？
拿单页面应用来说，路由页面A只用加载a.js，路由页面B只用加载b.js……如果你把a，b模块都引入不是在a，b页面多加载多余js？
其实模块化编程讲究的是复用，按需加载，安全。

每个模块1000-2000行代码，已经属于比较大的规模了，个人感觉应该引入模块化的机制。
使用JS的模块化开发方式，需要认识到开发、部署是两种模式：
在开发模式下，所有代码在手工编写的原始状态，调试、排错等和以前直接写函数没什么区别；
等到发布的时候，需要进行js和css的合并和混淆，是另外一个运行方式。

发布过程requirejs已经提过了完整的解决方案，配合一些插件可以完成js和css的打包。而且打包的范围也可以很灵活的配置，综合性能肯定比未做处理的原始状态要好，尤其对移动设备，可以大幅度降低页面中的js和css请求数量。requiejs官方已经给了一个比较完整的例子，可以参考使用。
https://github.com/requirejs/...

其它答案都很好，我提供个简单的思路好不好
其实可能是题主写的前端代码不够多，或者题主接触的大型前端项目不够多
诚然在一些小项目真的没必要引入这么大型的模块化机制，比如活动页面啦blabla

但是，如果你的互联网产品是很看重前端的，比如当今很流行的各个社区啦、电商啦，你要写的js就真的不是一点点了。
为什么很多语言都有类、模块，很大程度是为了抽象出逻辑，让每个逻辑束缚在一个文件里，让每个开发者容易互相合作，你不能否认，大多数情况下，两个开发者比一个开发者开发速度就是要快。