Hello and thanks for the suggestion!
It has been well over 3 years now since we started on the journey of renewing the front-end side of Foreman. Despite a lot of effort, and having a dedicated UI team for the past 2 years as well as many other developers involved, we are only now at a point where we have some of the groundwork for working with react - basic things like allowing plugins to extend core pages, the ability to share modules between core and plugins in a reliable way, and some of the base components that can be composed to build actual pages.
While some progress has been made, we still have a lot of places that use one of several “legacy” implementations. This means we already have many inconstant pages that look “out of place”. If we start adding PF4 to the mix, that would mean even more such inconsistencies.
I think that our users will not be happy to have a mixed UI between the two - especially since it looks like PF4 is completely different in its styling to PF3. I also think you are underestimating the effort it would take to get there.
I would not be happy having to rewrite pages again to PF4, and I’d be concerned that by the time we are half-way there PF5 (or some other thing) would come out and we would need to start again.
I think a full rewrite is not feasible. We would still need to support the existing UI until the new UI will be ready, which I don’t expect will take less than a couple of years at best. All of this time, while having multiple developers working on recreating the UI with no value to our users. I believe some of the longer-time members of the @katello team can speak to the effort they undertook to rewrite Katello in angular (or take a look at Foreman and katello UI future from 5 years ago).
I don’t. Many pages render just fine with erb and are much simpler to create that way. There is no inherent benefit in doing things on the front-end, unless there is for example some extra value added by using react components that allow for better interactivity. Just take a look at the amount of changes it took just to get a fairly simple page from ERB to react - from ~25 lines ERB that are quite simple to understand, it became several hundreds of lines spread over dozens of files, not counting the tests. I’m not saying we shouldn’t rewrite things to React where it makes sense, but I don’t think our priority should be moving everything to the client side where there is minimal value in doing so.
Please keep in mind that a lot of the “Best Practices” around client side rendering come from the world of SaaS, where you want to minimize your server and network costs and offload as much as possible to the clients, while handling thousands of concurrent users. We are not in this world - the biggest foreman installations will have dozens of users at most, and they will mostly be connected on a very high speed connection to the foreman server. This means that many of the considerations that are big drivers elsewhere are irrelevant for us.
I think this is the biggest issue. I would not want to introduce yet another technology to the stack while we still haven’t finished removing things we wanted to get rid of 3 years ago.
Both flows, in my opinion, will take significantly longer than you expect them to, while providing very little value to our users in the mean time. I would love to be proven wrong, but if we still haven’t gotten rid of things like jQuery, jQuery-ui, deface, angular etc. (and aren’t planning to invest in doing so) - I don’t see how this doesn’t end up being yet huge effort undertaken and end up with yet another different way to do things that will in turn be abandoned when the next thing comes up.
As a final note, I think Patternfly team here is making a mistake in not having a clear and easy to perform upgrade path - which is exactly the second system syndrome that @ekohl was referring to.
Sorry for the long post and I don’t want to sound discouraging 
but there are some considerations that you are likely not familiar with yet as a new member on the team. I hope I shed some light on those.