I haven't used it in a production environment, couldn't get management buy-in. Same comments as Brent, it will slow things down. So do speed bumps, and red lights, and school zones. The point is that something is overwhelming the system, going too fast, using too much, etc., and it's impacting everyone else. Dial back 1 or 2 things and it makes the overall situation better.
Getting the classifier right is the most important part, that should be relatively easy for the PowerBI stuff, as it should have a distinct application name you can test (APP_NAME() function). If different queries are run by different logins, those can also be checked. This is harder to limit if people are sharing SQL logins, much easier if you can move them to Windows authentication.
You can also make your resource pools simple, just limit CPU_percent settings for starters. You only mentioned CPU as your impacted resource, if you can identify which queries are using the most CPU and find identifying characteristics, that can also tune your classifier, in addition to measuring an effective CPU limit. If you find those queries using too many cores, also limit MAXDOP in the workload group.
If you have a lot of cores, like 32 or more, you can play with CPU affinity in your resource pool, to move those loads to specific cores, leaving the rest available for others. This one is a bit tricky and something you'd arrive at, after trying pretty much everything else, like tuning the queries.
Lastly, get the data replicated to another system for the analytics people to query. If you're mixing OLTP and analytics on the same box you will all suffer. The "but we need realtime data!" horseshit is answered by Availability Groups, and if it's that crucial, they'll pay for it. If they WON'T pay for it, then it's not that important. 
edit: forgot to include link to Glenn Berry's DMV queries, these can help find high CPU queries: