High CPU and plan cache instability
This DBA.StackExchange answer gives a good place to start tracing the issue.
Specifically the linked Microsoft Docs - Plan Caching in SQL Server 2008 docs (albeit a little dated, but still useful) have a section called Plan stability-related reasons of batch recompilations that details all the reasons the plan cache can be cleared out (you should also read the previous section Causes of Recompilations for some useful info).
There are too many reasons to quote from the above article but the one section I find particularly interesting and might be the easiest place to start is the following:

The following operations flush the entire plan cache, and therefore,
cause fresh compilations of batches that are submitted the first time
afterwards: Detaching a database, Upgrading a database to SQL Server
2005, Upgrading a database to SQL Server 2008, Restoring a database, DBCC
FREEPROCCACHE command, RECONFIGURE command, ALTER DATABASE ... MODIFY
FILEGROUP command, Modifying a collation, using ALTER DATABASE … COLLATE
command

In my experience, I've personally seen developers schedule commands such as DBCC FREEPROCCACHE to run routinely and cause similar issues. (Additionally I've seen overuse of the OPTION (RECOMPILE) and WITH RECOMPILE clauses all throughout a database causing similar issues as well.)
If you can eliminate the above checklist then you should follow the rest of the guide in the Plan stability-related reasons of batch recompilations docs, maybe looking next at how often you guys are running DDL queries that would cause plan cache recompilation, and then how often are you guys updating statistics across the board.
It's unfortunately going to be an elimination game most likely and won't be a trivial issue to solve, but best of luck.