I don't have an specific existing example to point to but even if I did I would probably be cautious of suggesting you use it as a reference.
The problem is that experience is very subjective and it's effect and therefore your response to it in your UI is likely to be highly unique.
Your categorisation of your users in to groups (and making decisions based on those) could be problematic. People develop at very different speeds and therefore a hotshot with 2 years experience may well be a Ninja but a company stalwart of 20 years maybe on be on the Intermediate / Advanced borders.
Also the rate at which people understand and retain information is very different. Some read something once and understand it forever. Others might need to experience the same information several times before it is retained and others may never retain the information, but know where they need to go to find it.
Einstein was famously asked "If you are so clever, tell us how many inches there are in a mile". He answered "Why do I need to know that, when I can look it up in a book".
The point is that it's often not a good idea to categorise people and treat them differently without some imperial evidence about your specific users. Time in the field tells you nothing about their knowledge of the information in your UI or their ability to retain it.
So what can you do?
This is where the concept of UI state could be your friend. You can start with some sensible defaults on what you believe your users will need to see. You then analyse the usage of the UI and the state that it is left in : Which users opened which progressive discolours? When did they open them? Who left them open when they exited the app? Who opened them every time? Were they left open across sessions? Etc etc.
With that information, you can start to improve your sensible defaults and over time stronger patterns will emerge which can guide you as to your design decisions.
Even the UI remembering it's state for each user across sessions maybe enough to solve your problem.
