Command line converters are ok for a title screen or a small patch here and there, but when you start to get deep into development they really start to bite you.
As you add features you need to fix the order of things, or when you add things, have the maps and animations all update as well. When you modify an image and it adds a char here, the automatic conversion tools just happily rearranges everything. Then you have to go and edit your map blocks to match the new order, then you have edit all the anim data to match the new order. This turns add 1 tile into 4 days of boring slog. And that is on single layer, single map, 256 chars. I shudder to think what a 2 layer, 1024 char map would take.
If I have animating chars then I need to make sure they stay in a solid block, so I can just DMA in a slab of RAM. If I'm doing a rol/ror parallax effect then I can't have the tool mirror those 1 or 2 chars, and I need to make sure they stay in a fixed position. If I'm doing a palette cycle effect then I need to make sure that the colours are assigned to fixed locations on a fixed palette, and although I have other pixels that are the same colour, they then need to be assigned to a different entry. If I'm using the Char < X = solid, X < Char < Y = fall through, and Y < Char is no collide collision then I need to be able to have strict order control, be able to insert a char and have maps/blocks auto updated. If I have meta characters, like slope start, slope end etc then again.
The SNES way around this it to burn the ROM and RAM on a separate collision map, but then that is Y.A.T you need to make/update/maintain/document
Using an external tool to make the graphics is fine, there is no need to rebuild DP V or PS into the tool again, but it then needs to let me make a char into a file, import and convert it, then add it into the char set, map where I choose and set the params on it. The "old Skool way" is to put bounding boxes on your "sprites", and then you can encode data into said box. I.e colour 1 is used to denote Collision box, so you have two colour 1s in the top row and two on the left side. Then colour 2 might be anchor point. Colour 3 is 1+2 on the same pixel. Colour 4 might be used for another anchor point, say you are making a game like Alien 3, and you have N guns, you want the artist to be able to mark where the gun should be held, as each gun has its own sprites that have their anchor point. If you need more complex data, say you use AND masks for collision to achieve a more complex result, making the image Half-Bright, and then you paint the areas with the darker half. This then gives you a 6th plane for the AND mask, which you strip off and use the first 5 to generate the sprite data.
To avoid the PSD, TIFF mess I would recommend IFF, it is the battle warn, battle tested, won every victory, and still fighting file format. It's very light weight, very easy to parse and very flexible. Any "true" IFF tool will only edit the parts that it knows about and leave the rest of the file in tact. So if you have an ILBM chunk, and then you put your tile metadata into say a TLMD chunk, when a person opens the IFF file and edits the "image" the tool will save out the IFF file and keep the TLMD chunk intact.