Although on first consideration it seems very reasonable for RPi.GPIO's current behavior of disabling pull resistors when configuring an output, it turns out this isn't necessarily a good thing, and in some circumstances could cause real problems.
The "default" pull resistor settings are documented in the BCM2835 datasheet, but the details are a bit obscure. Specifically, it turns out that the defaults are not applied during a reset, although the pin directions are changed back to inputs. It indicates that the defaults are applied only in a power-off condition, which apparently includes both the initial state when turning on power, as well as actually removing power but which does NOT include a reboot, either via "sudo reboot" and friends, or even via a watchdog reset.
This behaviour has been confirmed on a pizero with a floating (no external pull) pin (GPIO25). On power-up it defaults to a pulldown (per the "raspi-gpio funcs" output). If the pin is configured with no pull, with "raspi-gpio set 25 ip pn", reading it repeatedly will show it sometimes 0, sometimes 1 (as might be expected) instead of always 0. Likewise, setting the pin to an output via RPi.GPIO and then rebooting will result in it being a floating input, reading 0s and 1s at random, rather than having the default pull-down still applied.
The problem with RPi.GPIO is that doing setup(25, OUT) not only does not let you specify a pull state (which I realize would normally make total sense), but it clears the existing pull state as it configures the pin. When combined with the above surprising behaviour of the default pull settings across a reboot/reset, it means all pins which are configured as outputs via RPi.GPIO will in fact become floating inputs (with no pulls) from the time the reset occurs until user code manages to run and set the pins as outputs again.
A workaround would be to ensure that every pin that will be used as an output has an external pull resistor. Unfortunately some designs may rely on the documented defaults (which are mostly DOWN, with 0-8 and a few others being UP), but in a non power-cycled scenario that won't give the desired results.
Another (imperfect) workaround, is to specify explicit states for any output pins in "gpio=" lines in the /boot/config.txt. This has several potential flaws, including the fact this doesn't apply until some milliseconds (perhaps hundreds) after reset, and it also requires hardcoding the desired states in the config file.
A better option would be if RPi.GPIO allowed one to configure an output without modifying the pull setting. This would match the "raspi-gpio set N op" behaviour, which seems to require an explicit "pu", "pd", or "pn" if you want to modify the pull state. That way, pins without external pulls could have their default pulls left enabled, and they'd be pulled properly after a reset when the pin temporarily becomes an input again.
In short, the current RPi.GPIO behaviour of coupling the disabling of pull resistors to the setting up of an output pin is not always desirable, and there should be a way of avoiding that. (It might also be good to document this unexpected "default pull not applied at reset" behaviour, as it seems likely few people have discovered it.)
Note the exisiting ticket https://sourceforge.net/p/raspberry-gpio-python/tickets/170/ which asks for a related behaviour and which would, if implemented, provide a mechanism to do what's required here.