On thing here is that you're conflating content creation workflow issues and runtime issues.
For runtime performance, you want to minimize the number of draw-calls you have to issue, and a good way to do that is to collect together a bunch of small sprites that have the same or similar properties into a single, large texture -- then, you can feed a list of triangles with different texture coordinates to draw various sprites from it. Same idea with array textures, it just depends on what your hardware supports -- Sometimes you might know at build time what's best for a platform (say, on a console or other fixed platform), sometimes you might know at deploy time (say, from the AppStore where you know (IIRC) what device the package is being deployed to), and sometimes you might not know until runtime (say, on a PC). For best performance, you want to defer the decision of runtime formats until you know what your hardware supports, but you might just pick a good middle-ground like texture atlases, sacrificing some performance to regain some simplicity.
For your content creation workflow, you want to focus on what's the most efficient way for you to work with the art assets, and to get them into your work-in-progress builds. You might prefer to work with individual image files, or there might be technical reasons for doing so -- like image characteristics or version control. Sometimes you might prefer to work with sprite sheets containing tightly-related images -- like a single character, or even a single animation of a single character. How you or your artists work on your game's assets is about 75% preference, tempered with 25% technical considerations.
But the important take away is that these things don't have to be (and probably shouldn't be) the same. That is, just because your game might run best with a texture atlas doesn't mean you have to create your art assets in a texture atlas -- all you need is a little command-line tool to assemble the texture atlas (or, your game could do it on the fly, if you're willing to give up some load time) from smaller files containing fewer images, maybe just one. You can make this a part of your build system, so that the assets are assembled together when you build your game.
I like to think of code, assets, developers and artists as being "on the near side" of the build system, and software builds, "run-time", and end-users as being "on the far side" -- Often what's best for the near side is different from what's best for the far side. The build system is everything that automates the process of going from the near side to the far side.