InDesign also doesn't support embedded profiles for incoming placed PNGs—an embedded profile is ignored and the document profile is assigned. I can't tell you why you can't include a profile going out. All of the major desktop browsers, at least on OSX, honor embedded profiles in PNGs, so it seems like it should be an option.

We have implemented an automated workflow

Is the automation scripted? You should be able to add the profile via scripting.

If the idea is to provide a screen proof in a browser, there are still problems even if you can get the profile assigned. Current desktop browsers on OSX honor embedded profiles and I assume the same is true on Windows, but iOS tablets and phones do not. If you export a PNG and assign AdobeRGB, its appearance will shift on a tablet or phone because the profile is ignored. It isn't clear what the assumed RGB profile is on iOS, but the further away from sRGB the greater the color shift. See this thread:

In current OSX browsers, images with no profile are displayed as sRGB. You can see this if you load an RGB image with sRGB embedded and the same image with no profile—the display of the two will be identical. If the same is true on Windows browsers you should consider setting the InDesign document’s RGB profile to sRGB. In that case you wouldn't need an embedded profile because the exported PNG will be converted to sRGB and the current browsers are going to assume the image with no profile is sRGB and display it as sRGB.

The other complication is that any color management requires a properly calibrated and profiled display. Embedding a profile might guarantee the correct numbers are sent to the screen in some browsers, but that doesn't mean they will "look" correct when displayed or match the printed output. Having someone making color decisions on an un-profiled monitor is a disaster waiting to happen.

The other complication is that any color management requires a properly calibrated and profiled display.

That's fair to say, but on the Mac side all new machines come with a display profile installed, so an OS and browser color management system is in place out of the box. You can argue that you might get a better profile of the display if you run a hardware calibration, but there is a native white point and gamma described by the installed profile. So it would be wrong to throw up our hands and say don't bother including a source profile because we don't know what the state of CM is on anyone's machine.

In OSX browsers, I can see RGB images with no source profile convert into the monitor's RGB space as if the source is sRGB—an image with no profile or an sRGB profile will display the same. So if I'm not going to bother including a profile the best approach is to convert all color into sRGB.

More than subtle browser color problems happen if I don't convert to sRGB and also don't embed a profile. If I work in a big gamut space like ProPhotoRGB and save without an embedded profile there will be a major color shift in the browser that doesn't relate to monitor calibration and profiling. CMYK with no source profile will create a similar problem, which you can see in the link I posted in #6.

Here's an example of a significant browser color shift due to a missing source profile. On the left an image with ProPhotoRGB embedded in InDesign, in the middle the image saved as a PNG with the ProPhoto profile embedded and displayed in Safari, and on the right the file saved with no profile embedded:

So yes it would be foolish to use a web proof as a sign-off for print, but the ProPhotoRGB image with no profile would be very misleading and not useful as even a preliminary proof.

I think the conversion to sRGB would still be best approach if there's no browser CM. It's easy enough to test for CM, save the same image with ProPhotoRGB embedded and with no profile and open them into a browser and see if the color is different, if it is the browser is color managed. I'd be surprised if Chrome and Firefox are CM'd on the Mac side but not on Windows.