Matt

Already in v5.
I think the sensible thing to do is wait for all the news of v5 to come out and then make an informed decision on your future. Trying to extrapolate v5 from a few dev blogs may lead to rash decisions.
I'd love to keep you as a customer, but if you do wish to move to xF then on the plus side you won't need to worry about new versions and there being significant changes in your future. 😄

Already in v5.
I think the sensible thing to do is wait for all the news of v5 to come out and then make an informed decision on your future. Trying to extrapolate v5 from a few dev blogs may lead to rash decisions.
I'd love to keep you as a customer, but if you do wish to move to xF then on the plus side you won't need to worry about new versions and there being significant changes in your future. 😄

Again this bogus statistics gameplay. Jeez .....u had used same logic for removing support desk/ticket which everyone said, it's working fine. 
Anything that you want to remove, use the stats card. Without plugins, I wouldn't use IPS because IPS Nexus/Commerce can't even do basic donation tracking which every community needs. 
We love IPS and many are here since V2,V3 or even before versions... but with V5, it feels you want to go pro-cloud, make it standard for all and remove features which you think are not required without having 2nd thought for what your customer needs. 
Why you need to push us to XF man..... I am not touching vB for sure.. so only choice XF for me. 

He will stare at me without blinking until I add in new tools. He can be quite scary.

That is correct, you can add, but you cannot remove or modify existing data.
We do have a limited template front-end hook system (yet to be blogged) but that again does not have a replace option.

What do you need to do that custom profile fields can't do?

PHP just started crying.

Sounds good. 

Great! Now we need to experience it in practice. 👌

For now.. dum dum duuuuuuuuum. We have no plans to remove it.

As always, we are listening. We have a lot to announce yet. 

He will stare at me without blinking until I add in new tools. He can be quite scary.

For now.. dum dum duuuuuuuuum. We have no plans to remove it.

For now.. dum dum duuuuuuuuum. We have no plans to remove it.

For now.. dum dum duuuuuuuuum. We have no plans to remove it.

He will stare at me without blinking until I add in new tools. He can be quite scary.

I was just curious to know if most people just use the base IPS with the official apps and don't care about using third party apps/plugins.
That is indeed an advantage. And third party developers will also save some trouble because there is less risk of new IPS version breaking their apps.
If it's something that needed to be done, i guess we will all survive like it happened in the past with other major changes.

Correct, there is less opportunity to overload/hook into/touch Invision Community 5. If you can give me some examples of why you'd want to overload those methods, we can help guide you to newer tools or understand why there is a need and consider adjustments to the dev toolkit.
Monkey patching (code hooks) were convenient but the cost was very high in that we couldn't significantly alter our code without destroying most existing modifications causing WSOD, ISE500 or other errors on client communities. As PHP 8 becomes more strict about typing, return types, etc - a simple function signature change could break modifications.
Clearly, allowing almost every single class and method to be overloaded is not something that we could continue doing.
We also want to be a little more protective of some of our UI and flows. We want to build a toolkit that lets you build amazing add-ons and extra functionality but it will mean there is less scope for smaller apps that change some of our existing functionality.
The good thing about these blogs is that we get to have a conversation and learn from each other.

The capability to change how most stuff in IPS works and enhance it with own features/apps isn't going away.
What changed is how things have to be done. Some changes will be much easier, others will be probably annoying as hell for people who are used to how the hooks worked in v4, some will think that it is a huge step backward, but as Matt said, it had to be done, to provide a much more stable and faster-improving code base for v5, because we'll be able to alter or even deprecate methods, method parameters and even deprecate complete (internal) classes much faster, which also 3rd parties and clients will benefit from.
With v5 I'm really expecting fewer "A new community release with some huge under-the-hood BC breaking changes is here, all my apps are now broken and need to be updated ASAP" scenarios.
 
Code listeners are a quite common pattern used in modern applications, most php framework use this approach today. It's the perfect balance between none capability to change the core behavior via 3rd party code and the too-powerful proxy autoloader which we had in 4.x, which as powerful as it was, had also way too many problems.
I've read about concerns about missing event locations which were common in v3 and that it took ages to have new hooks implemented => Keep in mind that we have now a monthly release cycle, so I'm quite sure it's not going to take now that long to ship improvements as long as they make sense and fit into the general vision of the product.

He will stare at me without blinking until I add in new tools. He can be quite scary.

Probably... and due to that, the devs get tired of releasing new stuff and it gets a couple of purchases. There is certainly more to it than that.

Is that a cause or effect?
 The number of offerings in the marketplace has dwindled significantly during V4's lifetime.

Not every person has applications/plugins associated with the Marketplace. Many people downloaded the resource in xml/tar format and just installed it.
There are definitely more installations. IMHO.

I'll repeat what I said in my first blog:
We are being very intentional in restricting what can be changed with regards to our functionality and UI. None of this is by accident or an unintended consequence. We are providing tools to create features that side alongside our functionality, and less opportunities to replace our functionality.
We will have a better suite of development tools to enable this.
The third party developers are very important to us, but most customers choose to not use add-ons or modifications. Based on statistics we collect, the most popular plug-in on the marketplace has less than 250 current installations, and the most popular application has less than 600 installations.

I completely understand the anxiety and I get the fatalism, but please have patience. Wait until we have laid out the suite of tools. Then consider if some of your mods are even worth porting over. Consider your highest quality apps and then let us know if you need guidance on how to migrate them to v5.
Remember this is breaking news. Some of this code was only finished a few days ago. We are in the pre-pre-alpha phase. We are releasing news and listening to feedback, so there is no need to panic.

Also keep in mind that v4 will be maintained until 2025 at least.