Calculate the hash of mined block using stratum parameters (coinb1, coinb2, xtranonce1...)? Miners get several parameters from the stratum pool: coinb1, coinb2, xtranonce1, xtranonce2... according to here.

I wonder if it is possible to reproduce the hash of one already mined block, but using that info and going all the way trough, and not just the merkle root from the block.

The only way I could think of is if, somehow, those parameters could be retrieved from the block. Since there are hashes involved to calculate the merkle root, I would say no... but I'm not sure, or maybe there is another way. 

Thx!
When a pool gives a miner data to mine it is not data for one specific block, but a template for a block. The miner hashes many variations of this block data to try to find a block that has a hash value below the current target (which is determined by the current difficulty).

To calculate the hash of a block on the blockchain given only the data that the miner was given from the pool, you would have to do the same thing the miner did. You would have to hash many different blocks in search of that low hash - only then would you know the exact data the block contains - assuming you are not allowed to look at the block data on the blockchain.

For the old getwork protocol the pool would only allow you to set the nonce value in the block header. Everything else in the block was determined by the pool server. So you would have 4 bytes (32 bits) to search to rediscover the block someone mined with the given getwork-data. That's 2^32 (4294967296) different blocks. On average you'd have to search 50% before finding the right block. That's 2147483648 hash operations to perform on average. This is done in an instant with modern mining hardware.

With the Stratum protocol it gets worse. Stratum allows the miner to modify the nonce and a part of the coinbase transaction called "extra nonce 2", the size of which is determined by the pool, but usually 4 bytes. This means the miner has 8 bytes (64 bits) to fiddle with. That's a lot of blocks to search through. 2 to the power of 64. Though on average you'd only need to try 50% of those blocks.

It's actually a bit worse than the above because the miner may have also changed the timestamp on the block (ntime field of the block header). It would be a value close to the original timestamp though.

Usually pool servers push new work data to miners quite often. If you have equally fast hardware to that which found the block, then you should be able to do the above search in less than a minute. But that assumes that your miner and the one that found the block search the nonce and extranonce2 (and ntime) in the same way. For example if both miners start with a value of zero for nonce and extranonce2 and then increment from there, then it should not take long at all.