基于vue-property-decorator的Vue2项目迁移Vue3方案选型咨询

我维护着一个规模较大的Vue2项目，技术栈包含Vuetify、vue-class-component、vue-property-decorator与TypeScript，组件采用类风格语法编写，示例组件如下：

（为展示语法对组件做了简化，无法直接编译运行）

我们对现有技术栈的满意度很高：语法简洁易懂，新老开发者都能快速上手，且在2-3年的使用周期内没有出现过实质性故障。当前Vue2官方支持即将终止，我们计划升级至Vue3，但在迁移路径选择、方案可行性判断上存在较多困惑，调研许久仍未得到明确结论。我了解到Vue3推出Composition API有其设计考量，社区普遍对其评价较好，但我个人很难认同：除少量实用新特性外，Composition API语法理解成本高、存在冗余写法、显式声明过于繁琐，在我看来属于开发体验降级，以下是语法对比示例：

Props定义对比 #

// Vue2 类风格写法
@Prop({ default: '' })
label!: MyProp;

// Vue3 Composition API 写法
props: {
  myProp: {
    type: Object as PropType<MyProp>, // 略显怪异的显式类型定义
    default: ''
  },
}

变量定义（函数定义逻辑同理） #

// Vue2 类风格写法
myValue: string = ""; // 自动具备响应性，可直接在模板中使用

// Vue3 Composition API 写法
setup(props, context) { // 必须在setup函数内定义才能在模板中使用
  const myValue: Ref<string> = ref(""); // 必须通过特殊显式语法声明响应性
  return {
    myDataValue, // 必须从setup函数返回才能暴露给模板
  };
}

计算属性对比 #

// Vue2 类风格写法
get myValue(): string {
    return this.myDataValue.toLowerCase();
}

// Vue3 Composition API 写法
setup(props, context) {
  const myValue: ComputedRef<string> = computed(() => {
    return myDataValue.value.toLowerCase(); // 访问响应式值需要额外加.value后缀
  });
}

即便我们最终决定采用Composition API，全量重写现有代码库的时间成本也极高，难以承担。
我曾参考相关技术指南，从零搭建基于Vue3 Options API的类风格组件示例项目，将部分现有业务组件迁移到该项目中，经过少量适配调整即可正常运行，并未消耗过多时间。因此待Vuetify 3正式发布、可正式启动迁移工作时，我有以下几个疑问：

1. Vue3 Options API搭配vue-property-decorator是否是具备长期可行性的迁移方案？
2. vue-property-decorator库已经两年未发布更新，也没有官方提供的Vue3支持文档，在Vue3项目中使用该库是否存在极高的技术风险？
3. 投入大量时间成本将现有类风格代码全量迁移至Composition API，是否真的具备足够的收益价值？

感谢各位的解答！

2023年1月8日更新 #

正式迁移前我们对Vue3 Composition API做了多轮测试，其语法设计和相对繁琐的使用逻辑，最终让我们选择了vue-facing-decorator方案。该库的使用体验和vue-property-decorator基本一致，截至目前我们对该选型非常满意👍
非常感谢大家提供的建议与经验分享。

内容的提问来源于stack exchange，提问作者Farsen