AT89C5131A-UM Microcontroller
Without additional detail such as number of GPIOs and ADC pins needed, timers, package constraints (can the project handle wafer-scale ICs or BGAs?), and actual constraints defining "small" (size, pin-count, other?), a specific answer is impractical. 

However: Identifying a suitable "small" microcontroller is a much-detested but essential step in many of my designs, so here are some of the typical steps.


List out all pin requirements, e.g.

How many GPIOs needed
How many ADC pins needed
How many of the GPIOs need to be directly mapped to timers
Hardware serial (UART / USART / I2C / SPI) pins needed - Those generally map to specific pins
Pins that require input state-change interrupt support (if the MCU has this at all)
Inbuilt comparators needed (if the MCU has this at all)
Internal analog reference pins (if the MCU has this at all)
Any other specific pinouts needed, e.g. DAC or PWM pins (if the MCU has these at all)

List out all peripherals or functionality required within the MCU, e.g.

Timers
High resolution (16 bit or 32 bit) timers
Hardware PWM
Hardware UART / USART / SPI / I2C
Internal RC oscillator clock source
Analog comparator
ADC
DAC
USB PHY
Real Time Clock
Low power / ultra-low power modes
Amount of RAM, FLASH and EEPROM storage

List out package constraints, e.g.

What formats are acceptable: BGA? Wafer-scale? Chip-on-Glass? VQFN? SOIC? Or only DIP?
What is the minimum pin pitch the production process can use? 0.5 mm? 0.25 mm? Or no smaller than 1.27 mm?
Must the MCU be available in both DIP (for prototypes) and SMD (for production)? 
Must the package support the use of a ZIF programming socket before insertion into production boards?
Is there a physical board area constraint that might require cutting down desired functionality just to fit in the available space?

What are the price constraints? 

For small volumes on a client-billable product, this may not be a constraint, but for huge volumes, a 1 cent price difference adds up to a fair bit. 
Also, discount patterns for volume purchases vary widely between parts, even from the same MCU manufacturer

What are the end-of-life constraints?

For a guaranteed single production run, even an obsolete part may be viable if available in new-old-stock.
For a product expected to see production over the next 10 years, a manufacturer's commitment of part availability makes or breaks decisions

What are the lead time constraints?

Some parts, especially niche products or packages, and some manufacturers have big lead times, so even if a first production run can be met with existing stock, there may be logistical nightmares in the future. 

Second-source or minimum-rework (code compatible) alternatives

The lower end ARM parts sometimes allow switching manufacturers and specific parts with reasonably small effort
Some 8051 compatible MCUs are drop in replacements for each other
Sometimes code compatibility is good enough to permit entirely changing the product family without massive redevelopment, e.g. if using the Wiring platform (e.g. Arduino, Energia), switching between AVR and Tiva-C may be viable



I am sure some of the stalwarts on this site can add a large number of other parameters, but the above points are a good start.

Once all these parameters are defined, a parametric search on the manufacturer's site is generally the best way to narrow down the choices. Even so, a careful study of the datasheets of shortlisted products is essential. For instance, the Atmel atMEGA168/328 DIP versions have 2 ADC pins less than the SMD versions, while being internally identical. 



After analyzing all the above parameters, a decision that is not tightly tuned to the defined parameters often still makes sense. For instance: 

The Atmel ATmega328 and the Texas Instruments MSP430G2553 are personal favorites because then have both DIP and SMD packages available, boast a good number of GPIOs each, both have decent amounts of memory, and are widely used, hence ensuring extended availability and excellent volume pricing. Thus, there are some designs where a much smaller package or a simpler MCU would amply serve the purpose, but the NRE cost saved by reusing code from earlier projects makes it worthwhile to stick with one or the other of these.