Oh dear. I didn't read the question properly did I?
The fundamentals of escaping the output remain though, you have to escape data in readiness for the environment which will be the next destination.
So, in my (mistaken) reply, PHP data is received in one hand (where it should be Filtered against expectations) and in the other hand then escaped for the SQL environment. The point is to avoid leaving yourself open to a bobby table type SQL-injection attack.
Now, when taking stuff out of a database for display, say, on a webpage (again pretty much the PHP web scenario) then it is incumbent on us to protect other users (ie viewers of your webpage) from XSS attacks, whereupon bad things can be injected as say JS calls in a html attribute.
PHP has inbuilt functions to accomplish this. (htmlentities() and so on).
The use case might be this:
$incoming = "Some text I entered into your blog comments <script onload=alert(cookie)></script>";
While that can be escaped and put safely into your database, when you get it out and display it -- it can have consequences for viewers of your webpage. That cookie value can just as easily be sent to another website.
You might escape values differently if it was going to a pdf file, a csv file, or on to your mail() handler.
The rule is FIEO (Filter Input Escape Output).
The OP mentions sanitizing the incoming data and asks why it needs to be escaped again, well if you are dealing with a phone number and that matches a known format and you enforce that format, then arguably you do not need to escape it when you display it. If it is a free-form text input as you experience in blog comments then it is almost impossible to successfully sanitize the data.
This site scarily demonstrates the range of methods which are open for attackers to use in order to create, say, a <script> tag in any form element you have on your page. (they could also send it in via a cookie).
So, at the sharp end of your output can you be sure that the var $row['tel_no'] does not need escaping and that you are pretty sure that $row['comment'] does?
Or should you fall back to escape everything in principle just in case you, or some other coder did not Filter and perhaps sanitize the data in this particular case?
Some other reading here protect XSS attack php, PHP is not alone is having to protect users from XSS attacks and CSRF attacks etc.
I trust this makes up for my over-eager and misconstrued reply Sorry all.