Adobe's RTMP protocol, while close to RTSP, supported TCP only, thus losing all the advantages of RTP's UDP support in terms of network optimization but also gaining simplicity and, firewall issues aside, removing the complexity of NAT forwarding.
Initially the proprietary RTMP locked users into the Flash ecosystem - it was the only way for audio and video stream publishers to reach the widely distributed (and free) Flash Media Player, which had gained its ubiquity as a crossplatform browser plug-in that simplified the presentation for graphics and animations in webpages, and included audio and video presentation capabilities. The only way to generate RTMP streams was with the Flash Media encoder/ server combination, and at first the video enCOding and DECoding (CoDec) video compression choice was limited and was very low quality. However, the simple fact that when the player opened it would reliably open a video stream was a “magic bullet” and meant that the Flash ecosystem had a key economic driver that the other “more optimized” formats didn't: principally it worked for advertisers.
Very quickly it became interesting for publishers to add video to their sites because the Flash Player brought with it pre-roll adverts that played as soon as the webpage opened, and each advert brought the publisher money. Regardless of any other technology advantages under the hood, the owners of the publishing companies were enthused, so Flash video gained rapid adoption. This wasn't without exception - the enterprises still had to make the same “opt-in” policy decisions to allow Flash Media Player to install, and in fact even today many enterprises prefer the IP multicast enabled Windows Media Player model to ensure low impact of traffic during live webcasts on their LANs. However, the vast majority of streaming - both live and on demand - has rapidly moved to the TCP-based RTMP.