Annotation到底是“银弹”还是灾难？

随着软件越做越大、越做越复杂，配置文件也多如牛毛，于是我们开始在代码中写入Xdoclet Tag或Annotation代码，使用自动化工具生成相应的配置文件或者规避配置文件。
我开始想，配置文件的作用是什么？难道不是对软件进行解耦吗，比如在持久层和数据库之间解耦，以便更改数据库地址、用户、密码、表名之后不必再build代码。一个大型的开发团队可能有编码人员、架构师、测试员、部署员、数据库架构师这些角色，而且这些角色可能不由一个人担任。这些人之间的沟通也许不会通畅，客户与开发团队间也会存在沟通不通畅的时候，于是特别经常必需在客户的生产场所直接build软件，因为这时总会有代码与客户现存的生产软件之间有不匹配的地方，为便于修改于是直接选择在客户生产场所build。但是在软件交付运行之后，客户可能存在特殊的商业策略，比如定期更换数据库连接帐户的密码，这就不可能采用将密码硬编码在软件中的方法，因为每更换一次密码就要build一次软件这是不可思议的。如果采用配置文件就能解决这些问题。
问题是，既然配置文件是将易变的代码从硬编码的困境中解放出来，那么Annotation不是将一切回归原点吗？修改硬编码的配置再build软件和修改Annotation再build软件难道有区别吗？使用配置文件就是为了随时随地、容易的更改，而Annotation无疑让这些更困难了。
如果客户采用的策略是直接修改配置文件，那么他又不得不同步源代码中的Xdoclet Tag；如果采用Xdoclet Tag方式，那么他又不能较方便的更改配置文件；如果采用Annotation方式，那么他又不得不重复build软件。
我并不否认Xdoclet Tag的用处，在初次生成配置文件时它确实可以减少书写工作量，但是只要生成了配置文件之后，就要在同步Tag和配置文件上下功夫，这个工作量是以前所没有的。但是我实在搞不懂，回归紧耦合的Annotation到底好在哪里？Hibernate、Spring等框架一直致力于使用外置的xml文件来实现解耦，而Annotation一夜之间就让这些轰然倒塌。这些框架一开始费那个劲干嘛，直接做成硬编码不就好了。
因此，我在想对于开发团队来说，采用Xdoclet Tag生成配置文件的方式更好；对于客户来说，直接修改配置文件更好；对于Annotation来说，它本不该存在。