We have a (currently) 50-60KLOC SPA that, in the past 8 years, has survived migrations from a homegrown backbone+jquery-based MVC framework into angularjs (starting from v0.9), then to componentised angularjs v1.5 with webpack and TypeScript, to a heavily deangularised (but still based on v1.7) app where we've removed all useless DI (it didn't even help testing) and made all angular services into pure ES6 (well, in TypeScript) classes imported as modules, with Jest and TS transpilation via Babel.
We also have our own Redux/Vuex-inspired uni-directional state management solution that uses immer under the hood.
The next step, largely motivated by the fact it's hard to find developers who want to work with older frameworks, is to convert the app into Vue from the inside-out using ng-vue as glue, and when all components are Vue, remove the outer angular shell.
So we have been tracking these proposals. The original class-based RFC looked perfect for us, since that was 95% matching how our current (class-based) components look like. Seeing it get abandoned was a cold shower, but okay, not the biggest problem. Our components are as dumb as possible anyway, and we have all business logic in services. It'll just be some additional manual text-wrangling work.
The new proposal looks okay. I guess, just as React hooks made classes unusable in React, they had to go from Vue as well (though honestly, I don't really see the fascination with hooks, but maybe that's because we don't do anything like the Hooks examples I've seen in our app). I do really like the idea of the reactivity system being completely separate from the rest of the framework.
I personally never liked the original JS-only API either, with the { props:, methods:, computed:, } etc. "separation" (commenters here call it "simple", but I think it's far from that), so in my Vue 2.x projects I used vue-class-component.
Overall, the motivations and reasoning in this RFC seem sound to me.
However, here I come to my three biggest problems I have with this API:
1) The fact that you have to return the render props from the setup() function. It's annoying repetition, and I foresee people forgetting to add a newly added prop here. It also makes the definition of the component feel procedural instead of declarative. You have to read/mentally run the setup function to know the shape of the component. Hopefully maybe you can notate the setup() function return type to match a TS interface without breaking editor support?
2) The fact that they couldn't come up with a better-looking way to declare a prop with a complex TS type other than `prop: (null as any) as PropType`. I guess I could make a noop generic helper function for this, though.
3) props are optional per default. I feel this is the completely wrong default for a TS project (mentioned as a consideration in the RFC though)