What you mention is definitely a downside to this pattern, I personally don’t think it’s a big one however. I very much agree that using Object is dirty, too — I use Shape every time!
The way I see it, and the way I have experienced it, is that this particular issue doesn’t crop up too often. Usually, if a prop is purely a pass through prop, it’s unlikely I’ll be using it inside the container, so it won’t be caught by eslint. Similarly, if a prop is used for calculations inside the container component, it’s unlikely I’ll be also using it inside the dumb component.
You do raise a valid point, it’s just a hit that I personally think is worth it for the added simplicity that comes with this pattern. It’s also worthwhile mentioning that with this pattern the idea is to be able to reuse containers and components, in which case you would definitely want both container and component to check propTypes independently. I must admit however, this idealised view of the pattern doesn’t often work out in the real world and containers and components often become tightly coupled (even if only via props).
For your example, you could use the generateProps method I mention in the article. Since you’re spreading dc1Props and dc2Props into an object, they never actually show up in your container, so eslint has nothing to get upset about.