Maybe best would be to disable all policies until you can get a better hold on things.  This way all your devices stay enrolled and you won't have to re-enroll them.  Then get policies/configs setup like you'd like them to be and start enabling those policies.  

Also if you are a cloud customer, request a dev instance and get that all setup like you want and use Jamf Migrator to move everything over.

It sounds like first and foremost you need to evaluate what is currently in place. Take an inventory of your policies, configurations, smart groups, etc. What is the current order of operations and why? Determine what can be removed or replicated without impacting your end-user. It may sound obvious but a deeply detailed audit sounds like the first step in the right direction. 

In addition to what has already been suggested, I would suggest sitting down and writing out what you want your environment to look like when you're done:

• How do things get named inside of Jamf Pro (Policies, Smart Groups, Advanced Searches)?
• What Categories make sense for your environment? (Fewer Categories may make life easier)
• What is the Minimal Viable Product (MVP) for new devices? What's the minimal amount of software/settings that need to be applied at build?
• What does the new hire/new device process need to look like?
• What items do you want/need in Self Service?

In addition to @DBrowning suggestion to disable all policies, create a Category to put all of the policies in. I used a category named "zDisabled" for whenever we disabled a policy. That allowed me to go back later and use an API call to delete all policies from that category. But it also helps get those disabled policies out of your view as you start to build out new policies. I used Postman a lot for doing stuff like this, for making bulk changes to policies. (Shameless plug for my blog series on Postman and Jamf Pro: https://geekygordo.com/tag/postman/ ).

Configuration Profiles can be moved into that same Disabled category as well. But before deleting any profiles make sure that a) you're not going to break anything or cause unnecessary pop-ups/alerts for end-users, and b) that you un-scope the profile and let it sit for a few weeks before you delete it. Do not just delete a profile or you can cause a world of hurt for yourself with looping profiles and such. Un-scope the profile, wait for computers to remove the profile, and then delete it.

And a plug for two other tools that might help:

Object-Info 

Prune 

You can also find scripts for making local XML backups of Policies, Profiles, Scripts, EAs, and other items using Rich Trouton's scripts: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts  (he also has scripts to disable all policies and other things).

Wouldn't disabling policies break things for end users?

Wouldn't un-scoping end up breaking things for users that are already deployed?

Yes, it would stop all software from deploying and everything (except bookmarks) would be removed from Self Service. However, if you're concerned with how your policies are running, timing, etc, disabling all might be the best solution.

You don't have to disable all, you can just move them all to one category (although that will affect how they show up in Self Service) and then delete/remake what you want. You can use Jamf Migrator to download a copy of all of your policies and then pick through the XML to determine what you want to keep. There are several ways to do it, disabling might be the easiest.

Yes, un-scoping config profiles will break things. That's why I suggested you understand what the profiles do before un-scoping and only un-scope (then delete) if you absolutely have to. 

With any of this advice, especially around profiles, you need to test the behavior on a subset of machines. So have a machine that is scoped to everything, then un-scope that machine to see what the end user impact is. You can deploy a new profile and then un-scope the old and that should prevent end-user impact.

I think your questions are too broad which will get many expert advises that might confuse you more. I don't like using any third-party apps. I don't recommend them to the new users since they're still learning. I see you listed a few policies related issues. You can start with organize Categories, then clone the profiles and policies to test on a device first. Last time you asked about script and custom trigger, I hope you have resolved that, if not, you can send me a message and I'll see if I can help. 

Thanks for the links to all those scripts.  They look like they are for a on-prem instance of Jamf Pro, and my organization uses Jamf Cloud. Have you had success with these resources in cloud?

They will all work even if you are Cloud. I used a lot of the same scripts on my cloud instance.

Also, to @YanW point in the other reply, I went to full on advanced in response to your question, sending you things that might be too much to try. Start small. Write out what you want then start with just re-organizing Categories, etc.