Okay, I've not had much sleep because I had to get up early to go pick up the Christmas meat so apologies if I come across as terse.

With that out the way, I'm not sure what problem exactly this proposed paradigm is trying to solve.

TL;DR - this is an example used:

// Correct way
<BranchCount repo="facebook/react"/>
// Wrong way
<BranchCount count="102" icon="branch"/>

This pretty much sums it up - the "correct way" is already best practice and perfectly possible using, for example redux-based HOCs. We don't need a new paradigm to get this result. Just use composition.

Full breakdown:

I'll be using React as the basis for my analysis as it's repeatedly mentioned in the article. Let's go through the listed benefits:

scalability: highly scalable

I'm not sure how this is particularly scalable as no clear examples are given. Perhaps if you have a very tightly-coupled app with loads of prop-drilling etc it might be an improvement. Clearly, the author has some kind of scenario like this in mind when making these comparisons. But to me, if a codebase is in that state it likely indicates that not much thought has been put into its architecture full stop. Just following established, existing best practice would be a great first step in this situation - we don't necessarily need a new paradigm, feels like re-inventing the wheel.

moveability: much easy to move any component from one place to another.

AKA portability - makes sense, portability is good. But again, there are plenty of well-established patterns in React land that make building portable components very easy (e.g. separation of presentation and data/logic). And, in fact, this pattern makes components less portable, as they are tightly coupled to their data context. Fine if you want to move the whole thing as-is, but what if you want to shift the UI part to another app that uses a different API endpoint for example, or what if you want to use the same list component with multiple different sources of data throughout the app? Do you copy all the JSX into each "Business Component"?. It seems a bit odd to call the paradigm "Atomic" (suggesting the breaking things into the smallest possible unit size) when in fact it's proposing the opposite: taking presentational components and coupling them with their data context.

lego-pattern: since components can be moved very easily, we can truly build applications like lego blocks.

I'm not aware of a 'lego pattern' but perhaps the word pattern is being used casually. Nevertheless, the meaning seems to be that components are portable - this is the same as the above

loose-coupling: components don’t depend on each other.

Again, I'm not 100% sure how you can get into this situation if you've even spent a small amount of time looking at best practice. A combination of React's functional components and higher-order components make it incredibly simple to build "pure" components that are very easy to compose and re-use. In fact, most people will probably do this without even realising by default if they're using Redux for example.

removability: instead of using display: none, one can surely delete an old component without worry.

This doesn't make a great deal of sense to me. I can't imagine what a state one's code must be in where simply removing the reference to a component breaks something.

replaceability: we can replace one component at a time without worrying about breaking the entire application.

This is very similar to the above 2 points., and to reiterate just by following the path of least resistance and following examples in React/Redux docs etc you're going to end up with a codebase where this isn't an issue. Again it seems as though the author has a very clear picture of the type of codebase where this is a problem. Honestly, it sounds like a nightmare and I can't understand how you get there.

low-bandwidth: When designed with GraphQL, components only request minimum sufficient data.

I'm not sure how it's any lower bandwidth than any other paradigm (e.g. Redux with caching).

Okay, let's go through the "Problems and solutions" too:

P1. Multiple components fetching the same data-points.

Whilst caching is indeed a good solution as the article suggests - it's hardly novel or unique to this paradigm. Request caching is trivial to implement and can be used with any architecture. It's not a unique benefit of this paradigm.

P2. Reactivity & Communication: If one component updates some data-points then that change must reach the other parts of the application.

See: Redux, MobX etc etc - again this isn't a unique solution and is actually again, not an issue if you're following the general architectural trends.

And now the FAQs

Q1 — Difference Between Micro Frontend and ABC pattern? AFAIK, The micro frontend architecture is about loading multiple apps that are built using different UI libraries like React/Vue. We can still develop web-app using ABC patterns and use micro-frontend architecture to combine multiple web apps.

This is incorrect I'm afraid - Micro frontends are just loosely-coupled smaller apps as opposed to a monolith. There's no requirement or reason that they should be built using different frameworks. In fact, I would say that Micro-frontends are perhaps just a better version of this paradigm as you are able to compose multiple applications together in a modular way, lazy-load or dynamically fetch FE code etc. In short, the isolation is actually being used for something as opposed to having tightly-coupled data & presentational components that sit within a monolith where they could be benefiting from something like a shared global state.

Q3- I am using React or a similar component library. Am I using the ABC pattern? Without necessary discipline, One can write full spaghetti code using React where the entire application is fully coupled and a huge number of “props & data & functions” is passed again and again to the entire component hierarchy.

This seems to reinforce that the author has some negative experience with React codebases that are plagued by excessive prop-drilling etc. I don't want to speculate, but it seems like maybe the author hasn't taken much time to look at the existing solutions to these issues before creating a brand new framework to solve a problem that has already been solved.

ABC pattern clearly tells about not depends on any component and including parent itself.

This is especially telling as it just reinforces what I've said above. If you're making good use of stateless functional components in React (which should be the default direction people go in I would have thought) - then I'm not sure how you're ending up in a situation where your React components are dependent on their parents(!?)

There is no library or framework needed for the ABC pattern because it's an architecture pattern and the team needs sufficient discipline to follow it.

I'm not sure if the author is advocating not using a FE framework (like React) for large web apps - that seems a bit naive. It's also hard to imagine what this implementation might look like as there are basically no actual examples.

In conclusion, this seems like the author trying to work out solutions to problems they've encountered. Most of us have the tendency to re-invent the wheel if we're not careful but I would suggest perhaps that the author and those who are interested in this paradigm investigate existing best-practices first before embarking down this rabbit hole.

Again, sorry if I come across as a bit brusque, having a hard time being a human this morning, but I hope this is helpful <3