We have organised the Shrinking of the Data files on server and it went on well. Thereafter, it has again grows to its previous size of the LDF (Which is before the Shrinking Size) just after a transaction, I know due to its allocation (in terms of its occupational Size) that required for the LDF will gain its size. But what is the purpose being served with the shrinking?

Also, I have the Maintenance Job running to do the following like REINDEX, RECOMPILE ALL SP’s; UPDATE STATISTICS and CHECKDB which takes around 2 ½ hours but other day it took for the SAME around 4 ½ hours, at the same time the LDF’s which were Shrunk has regained its ORIGINAL SPACE.

The scenario you describe is exactly why you shouldn't shrink the transaction log down. Stop shrinking it as you are causing a performance problem since the server needs that space for maintenance jobs and large transactions.

There is no purpose to shrinking down the data files unless you know you no longer need that space due to a big purge of data or some other change in the database.

However, Can you explain how to use the checkpoint so that All the transactions which have been changed since then will be writting back to MDF location, using CHECKPOINT business. So that LDF transactions were liberated and fresh transactions can be stored.

Do not Shrink it - unless you have done a one-off huge deletion, or something similar which made the LDF grow unusually large

" Can you explain how to use the checkpoint so that All the transactions which have been changed since then will be writting back to MDF location, using CHECKPOINT business. So that LDF transactions were liberated and fresh transactions can be stored"

You don't need to do that. Making a Backup of the TLog will set the space used by all committed transaction as being "available" for reuse by new transactions. Thus the file will be reused, rather than growing bigger.

(This assumes that you are using Full Recovery Model, rather than Simple Recovery Model)