I'm a bit late to add my 2 cents, but here goes.
the number of atlases inevitably grows
Often you have a single atlas with many pages. You can control what goes on the same page with subfolders. However, it sounds like you are actually doing runtime packing, so you should have individual images until you pack them at runtime. If that's right, confusing that you mention exporting atlases.
Our goal is to reduce the overall asset footprint before deployment
You mean the unpacked PNGs? PNGs use compression and won't see a benefit from breaking them into slices. To reduce your PNG size without losing quality, use Oxipng (it's free).
Slicing might help pack your images at runtime, particularly because polygon packing at runtime is hard/slow so you'll just be packing rectangles. The gains shown at your link aren't anything like what you'll get though. They are slicing to compress full frame images.
my original concern was about the draw call increase that inevitably occurs as the project extends long-term
This can be solved with runtime packing of only the attachment images you will use, as Misaki explained.
Note draw calls aren't just about atlas page count. If you have 1 atlas page, you can draw in 1 draw call. As soon as you have 2 atlas pages, your draw count can explode. It depends on your draw order. Worst case is if every other attachment image is on a different page. If you can't fit in 1 atlas page, images should be sorted using your order to minimize page switches when rendering.
