I should have clarified and written that part of the article better, thanks for the comment!
My main suggestion for the use of package.json over index.js is primarily one of future-proofing your files.
(First, there is the simple benefit of one less thing to add to an import, the filename itself, but that's really the trivial change, although it's nice QoL imo)
The real benefit comes in the future when the project has grown and grown and all of a sudden you have some components that you want to behave in different ways in different contexts.
So in my examples given in the article, the "main" context was the one your app was initially developed for (probably browser), and you can add additional contexts by adding new keys (perhaps a "node" context, etc.)
This future-proofing is IMO the main benefit - it's just applying it from the start and assuming that it can grow in that direction as needed, instead of wasting time refactoring in the future when you're 40 components into development. Just admit it will likely need to happen at some point and adopt it now - it isn't an abuse, it's using webpack for exactly what it's supposed to be used for, bundling up modules properly. You're already using it because React, might as well *actually* use it so you're ready for future code requirements.
I've also found when working within teams it may also assist in coordinating how exports/imports are implemented when it comes to components and as such standardizes it on a component-sized level. Sometimes ppl like to fill index.js up with stuff that isn't needed, one dev prefers export default while another prefers export Component, etc. etc. etc. Just another code standardization method.
Like I said, technically, there are no best practices, but I think the two items I listed in this article are as close as I can come to best practices, with specificity to React.