Actually, wouldn’t it make more sense to just leave off the width and height, or leave it off if either exceeds the SiteSetting? Then I would expect the site settings to just override and do the right thing. It seems odd to have any width by height encoded in the markdown at all… I pushed a workaround to my branch that creates a method that doesn’t set width or height at all. I’ll let baking take care of that based on site settings.
Looks like I can fix this up with rake posts:remap:
Here’s what works within irb:
irb(main):001:0> s = ''
=> ""
irb(main):002:0> s.gsub(/(\!\[[^|]+)\|\d+x\d+\]/, '\1]')
=> ""
Regardless of whether we use " or ' in the shell, we need rather a lot of \ to call rake and have it work:
$ bin/rake "posts:remap[(\\\!\\\[[^|]+)\\\|\\\d+x\\\d+\], \\\1], regex]"
...
warning: regular expression has ']' without escape: /(\!\[[^|]+)\|\d+x\d+]/
Yes. Yes it does. 
Update: That posts:remap was effective on my test system with around 14K topics on it, but on the production server with 37.6K topics and 263K posts, as well as an additional 25GB or so of images, it failed partway through. It appears to have run out of memory; I no longer have the error message to reference and my recollection is hazy. It appears to have set off a storm of image reprocessing. The system is running a constant load of convert and optipng with a smattering of other image processing tools, to the point where it is making the UI slow.
I’m mentioning this operational issue here only for the benefit of the person three years in the future who finds this post from a search and tries a similar change…