Having an ingame browser and non-ingame browser is not that hard. Most coding bases have a browser base built-in that ties directly into the OS browser (IE in this case) for its browsing. Just like you can easily drop a browser window into an Android app or a windows script. It's already there.
It's actually more resource intensive to code for an out of game browser-based system because you to test against so many versions/programs (Chrome, FireFox, IE, etc.) and setups. Every one may display differently, something that an ingame browser does not deal with because it only needs to be coded for that one particular program.
I can't speak for any of the languages used for coding these games but I do know a little bit about HTML and error checking and correction is most likely a lot faster and simpler to do in HTML then it is in whatever language Frostbite 2 is written in.
The point still stands, and I personally believe its a big one, that not having to issue a patch anytime they need/want to make changes or additions to it is invaluable. I mean, think about it. In order for them to have issued a patch adding loadout changes to an ingame browser would require the coding obviously, but then they'd have to run it through extensive QA testing internally to ensure they didn't break any other part of the game interface. Once that's done, they'd have to work through the logistics of getting the patch out to people, ensuring they have the master servers geared up to handle the load and then there's still the possibility of their being bugs that got through or weren't seen on the system configs they had inhouse for QA. Isolate the new bug they introduced, develop the new patch, rinse and repeat till bug occurence levels are below whatever threshold they use.
Granted, these are all processes that DICE has done in the past and can do with ease but, look at how it can work on a web based platform. Code the new feature into a standardized platform that's, most likely (I imagine), a lot less complicated. QA goes through the testing that's most likely a lot quicker (again, guessing) and then the new code is uploaded to the master server for all to consume. If something goes wrong and a bug pops up, you pull the update and revert back to the fully functioning version and all your customers are relatively happy again. Find the issue, correct it, and reupload it to the master server.
Now, both processes are fairly similar and from my limited viewpoint I can't factually say that it costs less money for them to go with Battlelog. What I can say though for sure, is that the end user goes through a lot less headache, has to do a lot less to play the game, and assumingly, has to deal with a lot less headaches.