I agree that if it were a more inherently atomic part model in KiCad, it wouldn't make much sense to have a basic device button. But given that the schematic portion of KiCad is built to be more generic, it makes sense to be able to just drop in generic parts into the schematic as easily as possible and then fill in details as necessary.
Regarding the atomic/CvPCB argument, I'm sure this ground has been covered very heavily, but I think that it's a false dichotomy. Really both approaches fail to capture what is actually going on.
Really, there's several sets of data associated with a part that are all at least somewhat orthogonal to each other:
- the symbol - this captures the high-level logic associated with a part - e.g.: all 74HCT245s will be the same in this regard - 8 A<->B level shifters, an enable, a direction and power ports.
- the footprint - The physical layout of a part, both in terms of 2D board layout as well as 3D models.
- the electrical characteristics - pin capacitance, max/min voltages, signal propagation times, etc. This is a logical place to also store manufacturer info as the electrical characteristics are generally tied to a given manufacturer part number.
- The BOM - info about supplier price, availability, what the user has ordered in the past, future order planning, etc.
Really, any atomic part strategy that captures all the useful info has to tie these 4 things together. It's not just a footprint-symbol linkage with a part number tacked on. Eagle basically does that and I know that trying to capture the intricacies of buying parts from different suppliers, dealing with varying electrical properties on different models, etc was terrible.
If there were a sufficiently well-populated set of default libraries for these 4 datasets, even existing tasks like linking footprints to symbols is going to be taken care of in a lot of cases. E.g.: I pick out a 74HCT245 part for my project. KiCad can then follow the symbol-electrical/manufacturer links to give a list of different 74HCT245s available from different manufacturers with notable differences in electrical properties as well as the available footprints for each. I put some edge conditions on the acceptable electrical characteristics and select an available footprint from the manufacturere parts that match my criteria. That takes care of the footprint association and now I've got project-level data that allows constraints on the specific manufacturer part numbers that match what I want. When it comes time to deal with part ordering and management, it's easy for Kicad to just give me a list of compatible manufacturer part numbers and can search across suppliers to give me price breakdowns and availability all collated in one place for me to look at. I can also use KiCad to keep track of past part purchases to have a complete supply chain management system built right in.
Also, having things like electrical properties brought in as a separate units allow KiCad to add a bunch of very useful functionalities. For example, you could have the individual signal paths from a chip with characterized capacitance and driving power going to another chip with certain rise-time requirements. A built-in SPICE simulator can then easily tell the user if a trace connecting those two pins is too long, generating too much parasitic capacitance to meet the receiver's rise-time needs. Kicad can then look at alternate version of the chips with different drive power or rise-time requirements where the other electrical characteristics meet the user's requirements and selected footprint and list out suppliers, availability and pricing.
I realize that this is such a radical reworking of how Kicad would work that it's never going to be implemented. Even if the devs were willing to retool the program logic to that leve, it would require large numbers of automated data sources from the manufacturers to get all that data and make sure it's up to date. However, I think that it's still valuable to rethink the whole problem in terms of each part being decoupled into many datasets, not just a linked footprint and symbol.