Generally, microcontroller vendors put a range of memory in their devices that is suitable for typical applications. So, if you only need a few I/O pins and one SPI in a small footprint device, you will be unlikely to find anything that ships with 500 kBytes of Flash and 64 kBytes of RAM. With larger devices, which are closer to SoC packages, even the smallest is almost certainly big enough unless you're planning to do some serious number crunching such as image processing.
In a professional environment the key to picking the right microcontroller is to use historical data. You will have a record of the other projects you've developed and know what memory and other silicon resources are required to implement each feature. You will know what the product is expected to do and therefore have a good feature list and can quickly and accurately calculate the resources that the microcontroller will need to provide. Trying to guess the resource requirements from an up-front design specification (developed at the start of the project when the least information about the system is available) is unreliable at the best of times and only very experienced engineers, who have built up a comprehensive database of historical data in their own heads, will have any kind of success in using this method.
Many companies have adopted an 'Agile' approach to both software and electronic design, which involves building a 'library' of small, feature boards (e.g. RS-485 boards, ADC boards, etc.) along with generic platform boards that host the microcontrollers, in a similar way to using a dev-kit and plug-ins. A product can then be prototyped rapidly (within hours) by selecting and connecting the set of boards required for the features. The software is similarly assembled from library modules and can be ported and tested quickly. Once the size of the hardware-specific part of the code is known it is usually sufficient to select the smallest part that will contain that. The exception being the one mentioned above where the functionality of the device involves big data or very complex algorithms. This method provides an accurate, reliable and traceable methodology, using real data from real working products, rather than guesses based on hopeful specifications.
(Another advantage of the Agile approach is that it allows software and electronic development to be done in parallel, with the elctronics design being an exercise in integrating the set of feature boards and doing the relevant EMC and other difficult stuff at the same time as the application software is being developed on the protoype assemblies. Some porting and integration is still necessary, but it is done when working software and electronics are both available.)