Genadii Skaraev

If you are selling your house, you want to get the best possible price. If you place lots of ads in the newspaper and social media and have loads of people show up, you are NOT guaranteed the best price if your house "looks" undervalued.
The CSS Project is akin to advertising and the continued improvement of the suite will go a long way towards upping the site's overall perceived value.  Also known as "curb appeal".
It doesn't do us much good having lots of folks knock on our door if they immediately walk away to check out one of the other bright and shiny houses down the street.

Wouldn't it be easier on your staff, third-party developers and customers to improve upon CSS in a phased approach?
Why not break down the CSS Project into sub-projects? 
One sub-project you concentrate your attention on commerce.  You develop the "new" features you want to offer for that module while addressing any appropriate CSS changes needed.  You concentrate many IPS developer's and testers eyes on just that section of your overall codebase.
By concentrating "lots" of eyes on "one" module of the suite you will make it easier to identify any underlying performance, security problems or bugs. At the end of such a CSS sub project, you will end up with a much better underlying codebase then trying to tackle the entire suite all at once. Once that CSS sub project is "golden" you move on to the next sub-project
Upon release of the "CSS Project - Sub Project X" the third-party developers, theme designers and your customer base only have to make appropriate changes to "one" section of the IPS suite not the entire suite. 
By adopting a more phased approach you will significantly lighten the load and make it much less stressful on your third-party developers, theme designers and your customer base.

Errm, not wanting to spoil the snake-oil style sales pitch here. But, if you want to go and do some research, you'll find plenty of Invision based communities and websites doing very well in google. 
It's the core web vitals which can potentially have an affect on rankings due to the fact they measure things which affect user experience, and even in the apparently terrible example you posted for this site, they pass. 

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.
Here is a speed test of this very forum thread--and you use CDN with zero ads running--you score a 51%, which is an F for FAILURE:

 
After mostly CSS changes made with the ability to edit CSS files directly--the feature you just took away from everyone (and with the help of @Adlago), here is a similar forum thread on my site--I have no CDN and am running a large number of graphical ads:

What you see here is a site with mostly CSS changes, and it scores 25% faster than a site that is on a CDN with no ads. How is that possible? Perhaps you need to hire @Adlago because apparently speed improvements are still not on your radar, and now you've gone out of your way to strip the ability for those of us who actually care about this issue to be able to do something about it ourselves.

That is why I also wrote that the optimization process is individual, because each site uses different resources. I tried some time ago to derive generally valid content CSS rules... But after going into serious details, I became convinced that this is impossible.
Maybe if you create a basic css framework, with the most used rules, and have that file loaded via CDN with a single request, and all the rest of the css content in an install package, it will speed up mobile especially.

I understand your priority. I regret and apologize to you and the community here, for some of my harsher remarks.
What you have decided is a good idea, but my analyzes show that over 90-92% of css framework are unused initial loading of the home page, and also on pages for which the site owner has priorities for his users.
This is the basis of my last project that I was working on and yes, when all the used css rules are loaded in a quick file, such as custom css (one request only), while all other css rules are loaded as before - it no need for additional critical css. Of course, using such a practice requires direct access editing CSS.
Anyway, I was on the final stretch of my project and it's already been trashed...
I will look for other solutions...

@opentype Thanks for your opinion and criticism. I appreciate it.
To be fair - I'm using one of your plugins. I've never had an issue with it - it works perfectly on both desktop and mobile, for which I can only thank you - you're doing an excellent job.
On the contrary, I always write what I think. And how you perceive my thoughts is your right.

I agree that it would be much better to restore the ability to edit CSS templates.

I’m sure they do; but that’s when IPS can simply have an automated reply at the ready or even a tutorial link to resolve. So really it shouldn’t strain support at all and increase overall user satisfaction even though it is a trivial issue.
Designer mode is recommended to use on a test install. While that may work, it is an extra step which realistically feels like only expert theme designers use.
4.7.0 did introduce an easier way of adding CSS which is great for newbies, but again, I don’t see why there was a need to remove the intermediate option.
It was a very convenient way of playing around with (a copy of) your theme.

Page speed aside, there was really no need to remove the core CSS from the templates. I agree that most users do not need it so they would of course simply ignore it; but the ones that do need it had the option to view, understand, learn and modify if they wanted to.
CSS is basically harmless and any issue that may come up we could just restore the file to the original version so this shouldn't strain IPS support.
Basically: us self-hosters are already getting hammered with the cloud only features. There's no need to remove features too now.

Last night I went to work and built a new theme of mine based on 4.7.
In this theme I introduced my customizations in the accessible CSS.
Test scores - 100 points for desktop and an appalling 55-60 for mobile.
It is clear that IPS developers work actively only for desktop, and as it can be seen from tests on this site - they do nothing at all for mobile.
Given that they have neglected mobile, what is the point of preventing users from seeking their own solutions for mobile enhancements for their users...
I understand that IPS have ideas for modernization, but on a well-functioning version, to off the "fuel tank" because you want a motor to run on electricity is tantamount to a disaster...

In my opinion, what you are writing is about a qualitatively new version - for example, 5.0 with preset new parameters.
With small changes and bans in the existing versions of the 4.x family, you will only make things worse for your customers and probably turn many of them away....
Your idea is good, even avant-garde, but it will work only with a qualitatively new version - not with the 4.x family

I also cannot believe that you've removed this, and, after more than 15 years, and also looking at alternative boards to import my site into...totally unacceptable!
Your site speed is absolutely horrid...the only way I've been able to make my site get even average speed scores has been through extensive modification of CSS--now you've removed this ability from my--WHY??!!

For my part, I would be happy if all CSS were readable, as before, for reference even if not editable. The latest patch shows modified CSS and allows reverts of existing changes but unchanged CSS are still hidden and therefore, you can't use search.
It was so useful being able to search for something (even something as simple as a colour) and then quickly locate the code, copy it and then paste a modded version into custom CSS.

What do you want me to comment on this? My example is from a site where before optimization all indicators were bad.

Yes, I have done similar optimization on various large (with many users) sites. For each such site, it takes about 2 weeks of work - but after that, all Web Vitals are within normal limits. Here is an example from such a site

This is not going to help.
I do something else in the direction of optimizing the CSS when loading.
1. My custom css has another purpose - I have created new templates - first I load custom css - in this my custom css, I have created a copy of almost every css file, but in these copies content is only of used rules.
2. My main css (framework.css etc) is loaded from another template, following a template for custom css - so the browser extracts the used rules very quickly and starts displaying the page, it turned out that all the other rules from the main css are loaded quickly, but they do not affect the delay.
3. My real custom css I load inline css before closing head.
In this way, I achieve up to 95 points score for mobile maximum and 80 minimum, depending on server load.
This construction works optimally. I still have some work to do, but apparently I'll have to use designer mode, which will slow down my time a lot.

95% of your base CSS is not used effectively - and every online test shows it. Especially when a site uses external ads.
Also, there are enough ways to combine effectively used css into one css - and notice, without changing the structure of your development - just a small change in loading. Etc.
Any such change, even a small one, involves direct css editing... And a lot of testing and analysis... But it's worth the effort... This can't be done in designer mode, only in direct editing... It's individual for each site, each site uses different resources and requires different tweaks to improve... Etc.
With these restrictions you are now "scoring an own goal"...
PS. See your site

All this slows down the loading of the site, especially on mobile. With direct editing CSS and ...one more thing, a solution to this delay is found...

Restore direct CSS edit and everything will be OK

Apparently there is no point in explanations. I will easily go back to 4.6. And I will leave the community here. Unfortunately...
PS. I know how everything can change with a designer mode, but this is not a solution for the optimization of an active site, but only for a new development.
Sorry

Anyone who doesn't know what they are doing should find an acquaintance and pay themselves, or create an additional paid job for you. You can mention it in your product's terms of use. Which will justify additional maintenance payments on your support through no fault of your own.
But depriving the entire community because of units that give you headaches - that's complete stupidity...

Why did you remove direct CSS editing???
The entire suite is full of CSS errors anyway - and now you're complicating any improvement....
This version is absolute bullfaeces...
No performance improvement, but some absolute crap you've done...
I am so disappointed that I don't know if I will continue to be client...

If Redis is what IPS recommends, then why can't IPS let it be a recommendation, instead forcing clients to switch over? If Memcached is performing better than Redis for some users and they are comfortable with that (including myself as I host multiple servers and clients' IPS sites), or those clients who don't have Redis on their server due to their Host restrictions; then why to simply deprecate it?
My say: Please do NOT deprecate Memcached.

I have transferred one of my sites in Cloudfare to Cloudfront. I'm going to see how it works and I will inform you.