Because writing code is what programmers (should) do. If something is simple, then it is simple and won't take up time and energy. If you don't know how to do it, then learning how to do it is worthwhile -- especially if it turns out to be simple. If you make a mistake, then someone on the team must look at the code and understand the mistake. This means that the team learns that things that seem simple are sometimes complex and they learn how to recognise their mistakes. When there is a mistake, someone has to fix that mistake. They learn how to fix the problem. Other people on the team must review that fix and they also learn how to fix the problem.

There is always a balance between getting some extra productivity by using somebody else's code, or getting the knowledge, expertise and control of writing it yourself. Far too often I see young programmer's choose something off the shelf so that they don't have to understand it. This is a recipe for disaster -- for your project, for your team and for yourself.

IMHO, as programmers, we should err on the side of writing code. Often it is obvious that you should use standard libraries, or a particular framework or or another reuse library. But where it is not really obvious, I would start with writing your own code and see where it gets you. You can always replace it later if it doesn't work out. I think you will find that you and your team will be miles ahead if you take this approach.