"Return" is not the same as "print". Printing is a procedure of showing a result to the user; in general, the program can not make use of a printed value. Returning a value, on the other hand, is done for the purpose of further processing; the user does not directly get access to it.
To compare to real world: a subroutine is like a command to do a certain action; a function is like a question, giving you an answer that you can further ask about.
Imagine you are a foreman in a construction company, but you hate leaving your office. "Install a window on the south wall" is a command — a subroutine. A worker goes out and does it. Or "Take a photograph of the building, and show it to the client". The foreman does not get any information from that (apart from the confirmation that the worker has done what you asked).
On the other hand, "How tall is the tree next to the building?", "Is there any cement left?", "Ask the client about the photograph and tell me what his comments were" all give the foreman an answer, and the foreman can make further decisions based on it. This is what functions are.
If you have a function AreaOfRectangle that can calculate width muliplied by height, you can also have a function AreaOfRectangularBox that asks AreaOfRectangle for the area of the front, left and top face of the box, doubles each of those (since back, right and bottom faces are the same) and adds them together, returning the area of the rectangular box. The user still doesn't know what that number is, but the program does.
If you have a subroutine AreaOfRectangle, and it shows what width times height is on the screen, you cannot use this knowledge in the rest of your program, because AreaOfRectangle gives no information back to the program (except for the fact that it is done with whatever it was doing).
In some programming languages, subroutines have the ability to modify their parameters, so it is not so cut-and-dried, but still the distinction between "returns" (to the calling code) and "prints" (to the user) stays relevant. Also, in some languages, subroutines do not necessarily even have to report when they are finished (these are called "asynchronous"); but this too is a detail for much later.
EDIT:
returns double that value (in another cell)
Something like Range("A2").Value = Range("A1").Value * 2 is not "returning". This is commanding the program to store a value in a cell — conceptually close to a subroutine (and in some languages, it might be a subroutine — something like SetAt(X, Y, Val) — though VBA uses assignment to a .Value property). A program could later inquire about the value in that cell — conceptually close to a function (and in some languages, it might actually be a function — something like Val = GetAt(X, Y) — though VBA uses a simple access to a .Value property).
If you are using the return value of a function inside a formula in a cell, something like =DoubleThis(5), that is actually proper returning. But crucially, this is a formula, so basically it is still in the realm of code, not of the user. You could also write =DoubleThis(5)+7, and the return value of 10 would be used to be added with 7, for the total result of 17. (Then Excel takes over and displays the cell value; but this is not your code any more.)
Sometimes people use this word somewhat casually; but if you are learning programming, you have to strictly distinguish the two scenarios.