bash acts differently whether it is a shell or a normal programming language (like perl or python).
By design, the settings in ~/.bash_profile, ~/.bashrc, etc. are for users to set things when bash plays the role of a shell (login shell, interractive shell). Think about environment you have in a xterm (interactive shell) or in ssh sessions (login shell) or in consoles (login shell).
In other hand, bash is also a powerful progamming language –think about many scripts for managing services in systemd– which requires a different style of working. For example, when a developer is writing a system script or a bash program, he/she will not like to source the user's ~/.bash_profile automatically. It is a normal program, not a shell. A normal program (including bash programs) would naturally inherit settings from the current working evironement (shell), but not set them.
If we write a program for cron in bash –it just happens to be written in bash; in fact, we can write it in python or perl or any other progamming language– then we can have an option to sources bash's ~/.bash_profile (read: setting of user's shell, which just happens to be the same language of your programming language):
[ -f /home/user/.bash_profile ] && . /home/user/.bash_profile
However, what if that particular user do not use bash as his/her shell? He/she may use zsh, ksh, fish, etc. So, that practice would not really work when writing program for public use.
So, you can source ~/.bash_profile if you think that will work. But, here, it is not about whether we are able to source a file, it is about how things should works in the system: the design concept. In short: we should view bash as something having 2 roles: shell and progamming language. Then everything will be much easier to understand.