이런 경우 free로 메모리를 해제하지 않아도 될까요?

해제안해도 됩니다. 일반적으로 종료를 하더라도 해제를 하라는 의미는
그것이 좋은 프로그램 습관이기 떄문입니다.

가정 #1. 해당 프로세스이 종료될때까지, 해당 메모리가 필요하다.
가정 #2. 메모리를 해제한 상황에서 실행시켜야 할 로직이 없다.

위의 가정 #1, #2을 놓고 봤을때는 해제안하셔도 됩니다.
글쓰신분도 저 가정들 때문에, 굳이 해제할 이유를 못 찾으시는것 같습니다.

하지만, 저는 해제하는것을 추천합니다.
왜냐면, 가정 #1, #2는 언제든지 바뀔수도 있거든요.

소프트웨어는 꾸준히 성장하고 바뀝니다. 그래서, 방법론이 나오고
최대한 flexibility 와 molecularity 같은 것들을 고려하면서 프로그램을 짜는것입니다.

지금 사용하시는 로직(30GB의 메모리를 사용하는)은 해당 프로그램의 실행과 함께시작하여, 종료로 끝납니다.
하지만, 향후에 해당 로직을 다른 프로그램에서도 사용할수도 있고, 지금 프로그램도 새로운 기능을 추가하다보면
메모리 해제후에도 처리해야할 로직이 생길수도 있습니다.

그래서, 평소에 메모리 해제 같은것을 잘 처리해놨으면, 나중에 다른 용도, 또는 기능이 확장됐을때
좀더 완성도 있는 모듈이 됩니다.

소프트웨어의 재활용성, 확장성 이런거 하나도 고민하고 싶지않고,
그저 현재 가지고 있는 프로그램이 해당 로직의 전부이고, 아무것도 고민하고 싶지 않으시면,
그냥 해제하지 않으셔도 됩니다.

하지만, 그런식의 프로그래밍 스타일에 익숙해지고, 습관이 들어버리면
경력이 쌓였을 때, 고치기 쉽지않습니다.

프로그램에서 해제하나 커널이 해제하나 어쨌든 해제해서 풀어주는데 들어가는 리소스가 있긴 있겠죠

10분의 실행 시간이 끝난 후 종료될 때 프로그램에서 메모리 해제를 하는데 걸리는 시간이 "성능 저하"가 느껴질 정도로 오래 걸릴지도 의문이네요.

끝나는 그 순간에 있는 작은 성능 저하(메인 루틴에 의한 성능 저하보다 작을 것이 뻔한 성능저하)가 과연 같이 돌고 있는 다른 프로그램을 방해할 정도의 성능 저하인지도 의문이네요. 그런걸 고려해야 할 정도로 최적화를 해야 한다면, 메인 루틴을 1% 최적화 하는게 훨씬 더 낫겠죠.

이런 경우는 정말 해도 되고 안해도 되는 일인데, 정말 개인 취향에 따라 다른 것 같네요. 저라면 귀찮아서 안합니다. 문제가 생기면 그때 고려해보겠죠.

나중에 다른 코드를 더 넣거나, 유지 보수를 할때.. 의아하게 여길때가 있을듯 합니다.
분명, 할당은 하고 해제를 안하니.. 이게 멀까? 라고 말이죠. 완성도가 떨어져 보일듯 합니다.
머..실제 완성도와는 상관이 없더라도 말이죠.

malloc하고 free하지 않아도 OS가 알아서 메모리 해제를 알아서 해 주죠.
뿐만 아니라 thread, mutex 등등 resource 관리도 OS가 알아서 해 줍니다.

하지만!
malloc은 했는데 free 안하고 프로세스를 종료한다는 건
똥은 누웠는데 뒤 안닦고 화장실 나오는 것과 마찬가지이죠.

malloc(new)과 free(delete)가 매칭될 수 있는 코드를 고집하는 것은
개발자의 로망이자 예의. ^^

상황에 따라 좀 다르지 싶네요.
잠깐 쓰고 버릴 것(프로토타입 또는 개념증명 등)이나 혼자 쓰는 것이라면 제대로 돌기만 하면 상관없습니다.
하지만 팀작업이거나, 일정기간 유지보수를 해야한다거나, 인수인계의 대상이 된다면 제대로 만들어야죠.

또한 malloc과 free가 루프안에 있어서 성능이 걱정된다면(저는 그렇게 이해했습니다. 루틴->루프), 조금만 손보면 루프 밖으로 빼낼 수 있을겁니다.

어설프게 메모리를 해제하려고 하다가 세그먼트폴트 떨어지고 죽는 것보다
비록 메모리릭은 있지만 주어진 일을 다 해내는 것이 훨씬 좋습니다.

애초부터 메모리 할당과 해제가 명확하도록 설계되었고 그렇게 프로그래밍 했다면 좋겠는데...
전역 포인터를 남발하는 등의 만행을 저지른 소스가 있다면 메모리릭을 잡는다고 고생하는 것보다,
(게다가 어설픈 메모리 해제 때문에 세그먼트폴트가 떨어지면... ㅠ.ㅠ)
그냥 메모리 충분히 늘리고 정기적으로 해당 프로그램을 내렸다가 올리는 설계를 하는게 속이 편하지요.