Your situation (my interpretation)
It sounds like situation you have is ECM (Enterprise Content Management).
In such a scenario you essentially want a core product that serves up pages, documents, reosurces, ect and uses a core authentication model built in to the system.
Such a system would be a single application that supports scenarios like theming and customisation (think wordpress but more "enterprisey").
Whilst there is customisation there it's ultimately one core platform in reality and so the GAC won't benefit you ...
When should I deploy my assemblies into the GAC?
... the GAC caters for a scenario where you have a "Windows platform application suite" that all share some common "solid" components that are not going to see much change.
About your ECM situation
In your situation, the business will change often and so would those "versions" of that core stuff, the net result would be high overhead for your team in having to manage that GAC and over time lots of GAC's as you scale up and the configuration file hell that goes with it.
Playing devils advocate (Lets assume i'm wrong)
Take that a step further, lets say for completeness sake i'm wrong, then you have a situation where you're planning on a business model that involves each new client having a "new version of your product" each time so lets say it's 10 years later, you have 1,000 clients, this now requires at least 10 servers that all have this GAC management going on and each is hosting a subset of what is essentially "configuration on some core functionality".
your build and deployment process is heavily scripted using powershell to replace these core GAC based components on a large farm of servers which takes someone weeks of work to get running and with that causes massiv edisruption.
Normal "web deploy" type scenarios won't work for you either generating yet more headaches and causing more issues when you want to "migrate to the cloud".
I did make an assumption or two though
I'm assuming that the product in question is at least web based but ultimately cloud based and managing cloud instances is best done by deploying apps in to containers rather than to servers (ideal model).
Now you have a system that prevents you following the ideal model and you have to "unpick" your dependency on the GAC, but also the GAC to me feels like a legacy feature provided by .Net to serve a future than drastically changed in software modelling, the "common" approach these days with .Net core is to literally take the chunks of .Net itself with the app and deploy to any platform, many of which may not understand the concept of a GAC.
My advice
What I think is really going on here is your technical lead is concerned with code duplication (or assembly duplication) on servers, and is looking for a way to go to one place and manage that 1 copy of a given assembly which they see as being "the simplest way to do the job".
The reality here is that unless you are certain this is really needed, you're basically just adding overhead in to your dev process and any deployments and every time you change a GAC based assembly you have to regression test the entire machine in case that GAC change affected something un-expected (weather you use that version of the assembly or not for each app).
You're going to end up with massive config files that specify assembly binding redirections to the version you care about all over the place when in reality the better bet is to just deploy a "build" complete with the current build version of all it's dependencies, this is an awesome way to avoid what Java guys know as "dll hell" (never having the right version of a complete web of dependencies).
In short:
Just build / buy an ECM and provide a "pluggable" model that allows you to meet your clients requirements as much as possible without a change that requires any form of deploy.
In my case I built a system that allows for a certain amount of either code generation via tooling or configuration that causes different behaviour down known function trees.
