I think the article you link confuses two different things- bug tracking system is not the same as the bug handling process.
Saying "If it is non-critical, you drop it." doesn't mean you don't track the things you are leaving, tracking can be done in using any system you like and in this case it's the Kanban board. The opposite is also not true, you can still drop non important bugs even if you are using a tracking system.
How efficient is this process ?
In my Kanban we used to have periodic bug triaging meeting where old or non important bugs were simply closed, while trying to keep a zero bug policy- bugs that required big architectural changes were converted to new feature requests and closed, others were solved asap. We didn't have a dedicated bug tracking system but the relevant Kanban tasks were marked as bugs for clarity.
It was rather efficient for our product that was stable with high pace of development and relaxed stability requirements, I can see it being less efficient for new products where a lot of bugs flow in
How can you manage bug count >50 using 3-amigo. ?
I'm not sure what does it mean in this context, but having periodic sessions to evaluate bugs instead of reacting to them in realtime can limit the disturbance to the development flow.
On the other side if your product have too many bugs you should stop and consider your position- is it because of low quality ? because you are still under development ans stabilization ? in the first case consider stopping and improving quality before you continue development, and in the later you can probably safely ignore the bugs or tack them temporarily.
How do you keep the QA motivated if there are no way to track thier efforts ?
I don't see the problem here, bugs are still discovered and communicated why do you need a special system for that ?
What KPIs to use if the bug count itself is removed?
Bug count should never be used as a KPI in the first place, use the other KPIs you will usually use to assess the things you want to assess (or in other words, you need another question for that)
How do you prove that a decision of "not to be fixed" was taken by the PO or Dev?
Prove ? unless you are in a highly regulated field why would you want to prove anything ? a team is based on trust and team members not abusing the system. Anyway, Kanban doesn't mean that tasks are not being tracked, they are simply called otherwise in a non-dedicated system
How to prove that its not a defect spillage , but a decision of "not to be fixed "?
Same as above
How do you track the resolution made if a similar issue occurs in future ?
See the above, but that's really a disadvantage to using a general purpose system
How can bug fixes be assigned to developers according to available capacity?
That's the strength of Kanban- a bug is just another prioritized task in your list
How to validate that bug numbers are reducing with each Sprint ?
See above, bugs are still being tracked
What would be the real role of QA in this case ? How do you retest a bug if you don't have tracking at the first place ?
Same as before, only now it's a Kanban task and not a bug