最根本的原因：考虑不周，不够成熟。
虽然vue的各种东西都是经过很多讨论的，但是很明显再多人讨论也无法阻止语法糖始终会有争议。
首先，我很想吐槽顶层暴露给模板这个问题。诚然这会减少很多重复代码，但同时这也会造成一些必须在setup引入却不想暴露给模板的变量，有时候甚至会不小心覆盖掉一些框架或库默认导入到模板中的变量（例如$store等变量）。我记得之前的提案还增加了某些命名不默认暴露的限制，后面去掉了，所以无论你怎么命名都会被暴露。总而言之使用script setup的话，想要usexxx的时候，你可能不得不把这个东西放在script setup里面并忍受它会被暴露给模板的事实……
其次，定义响应式变量并没有更简单，还是一样的ref()，还不如我直接定义一个reactive并且在return里面...toRefs()呢，原来好像还有个ref: 的语法糖，后面也没了，真不懂在搞什么。即使可以用defineExpose来曲线救国，也不是一个好方法，总而言之并没有使得事情更简单。
接着，composition api的setup函数实际上跟script setup是冲突的，只要定义了<script setup>，你原本的setup函数就废了，也就是只能选其一使用。虽然本身script标签都可以共存，但是setup函数只能有一个，并不会智能合并。当然这一点我是可以理解的。
虽然说都像是借口，但是我丝毫没感觉这个script setup语法糖有多好用，甚至感觉还不如以前的options api，还是继续用script+composition api算了。
顺便说一下，composition api虽然看上去用法跟options api很像，但是还是有很多细节的区别的，比如取消了this的绑定，这一点我觉得其实更好，因为我们可以在setup函数里直接定义data并访问变量或方法，而不是像以前一样为了获得this一层一层套娃（因为回调函数会使得this的指向改变）。缺点就是需要程序员自己规范结构，不能像options api那样通过语法指定什么代码放哪里（个人项目还好，团队项目不规范的话那就太容易乱套了）。为此，使用vuex和vue-router等组件就需要通过引入useStore和useRouter等函数来获得$store和$router对象。这也是跟script setup水火不容的地方之一，我很喜欢按原来用$开头命名那些vue库的对象，但是这肯定会覆盖掉原本的对象，虽然可能不会有什么问题（实际上也出问题了，实测$store真的不能），但是真的很不爽啊这种感觉，不在生命周期内引入又没有用，所以不可能放到script下面的。
虽然我很高兴有这么一个“好用”的东西可以选，但是目前真的是爱不起来啊……其实我更想要官方出一个与常用周边库联动使用的demo，可以作为标杆，这样方向才更加明确，也更多开发者对这个语法糖参与讨论，而不是等大家摸索完以后发现p用没有的时候在那里骂骂咧咧的改回原来的用法……