dd has a default block size. Honestly, I don't remember what it is. Probably 1 byte or 512 bytes. If I do something where the block size matters, I will set it. Ideally right there, on the command line, so it is visible: no surprises. What are cases where the block size matters? I can think of two. First, some devices can only do IO at fixed blocks sizes (hard disks when using a raw interface, and in particular CDs). Second, block size can heavily affect copy performance. There are even correctness issues when making some copies which require blocks to be padded.
You could change the default. For example, you could go into the source code, adjust it to your taste, and recompile and reinstall. Or you could create a little script (for example /usr/local/bin/dd), which internally calls /bin/dd and overrides the block size. Either is a very dangerous idea, because there may be many other things in the system that rely on dd, and you might break them.
OK, so now let's talk about changing the default block size in some other way. Imagine that dd had a way to accept a change of default parameters, for example from an environment variable. You personally might find that convenient: if for example you use dd usually with a block size of 4096 (because you have modern disks) or of 2M (because you usually copy big files around), then it would be easier to not have to type the bs=... every time. But the same argument from above again applies: Environment variables are passed down to commands and subshells (usually, not always, for an example where the environment is not used see cron). So your default might break things.
Here is a better idea: If you want to override defaults, do so in a manner that makes it clear that you are not running the normal dd. For example, you could have an alias in your shell setup (.cshrc or .bashrc) which says alias dd_disk="dd bs=4096" and alias dd_fast="dd bs=2097152". Or you could have your own personal ~balanga/bin directory, with little scripts dd_disk and dd_fast that do just that. All these are fine things to do. Where it gets a little dangerous is if you use an alias to override the default behavior: it is perfectly legal to say alias dd="dd bs=12345", but doing so carelessly leads to the same problems described above. If you do this, make sure the alias is only used for YOU (not for other users that expect the normal behavior), and only for INTERACTIVE shells (not commands).
This topic comes up much more commonly with the ls and rm commands. People like to alias them, commonly to "ls -F" and "rm -i". There are risks there, if shell scripts distributed by others use the ls and rm commands carelessly; there are easy way around that though, for example always using /bin/ls and /bin/rm in scripts.