Why do BAM files created by different tools have different file sizes? I have a BAM created by Picard. I want to filter alignments by flags with samtools view. However, I noticed that even if I apply no filters, the output BAM is different from my input BAM. Are BAMs produced by different tools also different in size? How can I check if two BAMs are the same?
It's worth bearing in mind that when outputting compressed BAM, as most tools do by default, they may well be using different levels of compression and/or different libraries, or versions of said, libraries for doing (de)compression which will result in different file sizes.  Additionally coordinate sorted BAM will compress more than unsorted BAM. The current version of Picard uses HTSJDK which in turn uses java.util.zip.Deflater/Inflater, current versions of samtools should be using the HTSlib library which in turn depends on the standard zlib library. You can see the effect of different implementations of zlib have on file size and execution time in benchmarking done by the samtools team.

However, in your case the best way to see if there is any difference between the BAM files is to rule out the effect of different levels of compression or libraries used for compression and save both BAM files as uncompressed.  Both samtools and Picard have options for disabling or changing the levels of compression, since the BAM compression standard BGZF is implemented on top of the gzip format it has inherited the ability, just like with gzip, to change the compression level from 0 to 9.

samtools view -bu will allow you to produce uncompressed BAM output (which is also handy for piping into other programs as it saves time wasted compressing decompressing what is essentially a stream).  Also note that samtools sort has a -l INT setting where INT can be set between 0 (compression off, as with -u) 1 (for fastest compression, but increased file size) or -9 (for maximal compression, with increased run time).  Some of the effects of increased runtime for higher compression settings might be ameliorated using the -@ argument which allows you to set the number of extra threads used for BAM compression, by default samtools won't use any.  

Picard tools has a general setting COMPRESSION_LEVEL which is applicable to most of its tools setting this to 0, COMPRESSION_LEVEL=0 should disable compression. 

So re-running whatever Picard tool you used in the first instance with COMPRESSION_LEVEL=0 will then enable you to check that the file is not further modified by samtools view -bu. The assumption here being that if both files have exactly the same content they should be the same size uncompressed, of course if they have trivial differences with regard to white space formatting things may still differ.